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PREFACE 


Before  a  new  computer  is  installed,  it  is  common  practice  to  de¬ 
bug  its  programs  by  simulating  the  operation  of  the  new  machine  on  an 
existing  computer.  GLYPNIR  is  a  programming  language  for  the  ILLIAC  IV, 
a  computer  being  developed  by  the  University  of  Illinois  and  Burroughs 
Corporation.  To  facilitate  the  debugging  of  scientific  GLYPNIR  pro¬ 
grams,  a  GLYPLIT  execution  process  (GLYPNIR  to  PL/I  translator)  was 
devised.  The  present  report  is  a  user's  manual  for  GLYPLIT. 

This  work  was  sponsored  by  the  Advanced  Research  Projects  Agency 
as  part  of  the  ARPA/Rand  Dynamics  of  Climate  Program,  of  which  a  sig¬ 
nificant  element  is  the  use  of  the  ARPA-sponsored  ILLIAC  IV  computer. 

Thia  report  should  be  of  interest  to  those  facing  similar  trans¬ 
lation  problems  or  considering  the  differences  between  code  for  an 
ILLIAC  IV  type  machine  and  a  serial  machine  (especially  Appendix  A) , 
as  well  as  to  users  of  the  GLYPLIT  system.  The  reader  is  assumed  to 
have  a  working  knowledge  of  GLYPNIR  and  IBM's  360  Job  Control  Language; 
familiarity  with  PL/I  is  desirable  but  not  essential. 
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SUMMARY 

This  report  is  a  user's  manual  for  GLYPLIT;  a  program  to  trans¬ 
late  the  ILLIAC  IV  higher-level  language  GLYPNIR  [1]  to  PL/I  for  the 
IBM  360  [2].  GLYPLIT  was  developed  to  provide  a  mechanism  for  debug¬ 
ging  GLYPNIR  programs  before  the  ILLIAC  IV  computer  becomes  available, 
and  may  still  offer  a  f  jnvenlent  approach  to  debugging  such  programs 
after  the  ILLIAC  IV  is  operational. 

Before  a  new  computer  is  available,  a  traditional  approach  to 
writing  and  debugging  programs  for  it  is  to  simulate  the  new  machine 
on  an  existing  computer.  In  doing  this,  at  least  two  programs  are 
usually  written  for  the  existing  computer:  an  assembler,  which  trans¬ 
lates  assembly  language  programs  for  the  new  computer  into  the  new 
machine  languages  and  a  simulator,  which  simulates  the  new  machine's 
operation  in  this  machine  language  code.  The  University  of  Illinois 
took  this  approach  for  the  ILLIAC  IV  with  the  production  of  the  ASK 
assembler  and  SSK  simulator  for  the  Burroughs  5500  (and  later  the 
6500).  In  addition,  they  produced  a  higher-level  language  called 
GLYPNIR,  whose  compiler  produces  ILLIAC  IV  assembly  language  for  input 
to  the  ASK  assembler. 

Thus  potential  ILLIAC  IV  users  may  write  GLYPNIR  programs  and 
have  them  compiled,  assembled,  and  simulated.  Unfortunately,  the 
process  is  quite  slow.  A  typical  1000-card  GLYPNIR  program  takes 
roughly  2  minutes  to  compile,  7  minutes  to  assemble,  and,  for  3  seconds 
of  ILLIAC  IV  time,  10  daijS  to  simulate.  If  the  purpose  of  a  run  is 
hardware  simulation,  the  user  must  work  within  this  Illinoii  system; 
however,  if  the  purpose  of  a  run  is  to  debug  a  GLYPNIR  program,  then 
GLYPLIT  offers  a  faster,  more  economical  approach.  With  GLYPLIT,  the 
1000-card,  3-8econd  simulation  takes  roughly  7  minutv^s  to  translate 
to  PL/I,  6  minutes  to  compile,  and  30  minutes  to  execute  on  a  360/65, 
a  machine  comparable  to  the  Burroughs  6500. 

GLYPLIT  is  itself  a  PL/I  and  assembly  language  program  that  runs 
on  any  IBM  360  under  the  full  operating  system.  PL/I  statements  may 
be  freely  intermixed  with  the  GLYPNIR  to  be  translated,  making  the 
full  range  of  PL/I  input/output  and  debugging  features  available. 


The  translator  does  not  accept  full  GLYPNIR  as  Input,  but  takes 
a  subset  suitable  for  much  of  the  "scientific"  programming  (FORTRAN- 
llke)  expected  on  the  ILLIAC  IV.  As  alluded  to  above,  hardware-oriented 
features  of  GLYPNIR  are  not  translatable,  such  as  the  ability  to  in¬ 
sert  ASK  code,  the  alphameric  WAND  and  WIMP  machine  operations,  and  the 
explicit  specification  of  registers  possible  for  efficiency.  The  re¬ 
striction  to  scientific  GLYPNIR  programs  also  means  that  all  of  GLYPNIR's 
list  and  pointer  processing  capabilities  have  been  left  out.  However, 
these  considerations  will  not  usually  Interfere  with  the  primary  goal 
of  GLYPLIT :  to  facilitate  the  debugging  of  scientific  GLYPNIR. 

This  report  details  the  restrictions  of  the  GLYPNIR  subset  ac¬ 
cepted,  describes  user  control  of  the  translator  and  Insertion  of  user- 
supplied  PL/I,  describes  the  translator  output,  ani  discusses  the  IBM 
360  Job  Control  Language  necessary  to  run  the  system.  Several  appen¬ 
dixes  Inclua^  the  structure  of  the  generated  PL/I,  ^ielected  PL/I  com¬ 
piler  and  execv\tlon  messages,  translator  messages,  and  a  summary  of  the 
restrictions  of  the  GLYPNIR  subset  (Appendix  F) . 
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R-857-ARPA  USER'S  MANUAL  FOR  GLYPLIT:  A  PROGRAM  TO  TRANSLATE 
ILLIAC  IV  GLYPNIR  TO  IBM  360  PL/ 1 
R.  E.  Hoffman,  April  1972 


Page  5.  Under  2,2,5  Statements,  the  last  sentence  should  read; 

This  count  does  not  include  leading  and  trailing  blanks 
on  any  card,  or  user-supplied  PL/I,  or  control  cards. 


Page  16.  Mid-page  equations  should  read: 

(a(i)  DO  i^ij^  TO  subscript, 

((a(i,j)  DO  i“ij^  TO  i2>  DO  j=j^  TO  j^)  for  two  subscripts, 

etc.  (Of  course,  i  and  j  may  be  reversed  for  the  opposite 
I/O  order.) 

EX;  PUT  FILE(SYSPRINT)  DATA  ((A(I)  DO  1-1  TO  64)). 

Note  that  two  sets  of  parentheses  are  necessary--one  for 
the  array  specification  and  one  for  the  data  list. 

Page  33.  Line  15.1  should  read; 

15.1  //LRED.SYSLIN  DD  DSN=**.PL1L. SYSLIN,DISP=OLD 

Page  62.  A  twelfth  entry  is  necessary,  which  reads; 

12.  According  to  GPN/11,  GLYPNIR  initializes  all  local 
variables  to  zero  on  the  first  entry  to  a  block. 

The  translator  does  not. 
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1.  INTRODUCTION 


A  traditional  approach  to  writing  and  debugging  programs  for  a 
new  computer,  before  that  machine  is  available,  is  to  simulate  the  new 
machine  on  an  existing  computer.  To  do  this,  at  least  two  programs 
are  usually  written  for  the  existing  computer:  an  assembler,  which 
translates  assembly  language  programs  for  the  new  computer  into  the 
new  machine;  and  a  simulator,  which  simulates  the  operation  of  the 
new  machine  in  this  machine  language  code.  This  approach  was  taken 
by  the  University  of  Illinois  for  the  ILLIAC  IV  with  the  production 
of  the  ASK  assembler  and  SSK  simulator  for  the  Burroughs  5500  (and 
later  the  6500).  In  addition,  the  further  step  of  producing  a  higher- 
level  language,  GLYPNIR  [1],  was  taken.  The  GLYPNIR  compiler  produces 
ILLIAC  IV  assembly  language  for  input  to  the  ASK  assembler. 

Thus ,  potential  ILLIAC  IV  users  may  write  GLYPNIR  programs  and 
have  them  compiled,  assembled,  and  simulated.  Unfortunately,  the  pro¬ 
cess  is  quite  slow.  A  typical  1000-card  GLYPNIR  program  takes  roughly 
2  minutes  to  compile,  7  minutes  to  assemble,  and,  for  3  seconds  of 
ILLIAC  IV  time,  10  dccys  to  simulate.^ 

However,  if  the  purpose  of  a  run  is  to  debug  GLYPNIR  programs 
rather  than  to  produce  a  hardware  simulation,  then  GLYPLIT  offers  a 
faster,  more  economical  approach. 

GLYPLIT — a  GLYPNIR  to  PL/I  Translator — runs  on  any  large^  IBM 
System  360  under  the  full  operating  system  (OS) .  It  accepts  a  subset 
of  GLYPNIR  suitable  for  much  of  the  "scientific"  programming  (FORTRAN- 
like)  expected  on  the  ILLIAC  IV,  and  translates  it  into  PL/I  [2].  The 
PL/I  may  then  be  compiled  and  run  on  any  suitable  360,  and  the  results 
checked.  PL/I  statements  may  be  freely  intermixed  with  the  GLYPNIR  to 
be  translated,  making  the  full  range  of  PL/I  input/output  and  debugging 
features  available.  For  debugging  scientific  GLYPNIR  programs,  this 
GLYPLIT->-PL/I-+-execution  process  is  more  economical  then  the  GLYPNIR-> 

f 

Assuming  a  simulator  ratio  of  300,000  seconds  of  6500  time  to  1 
second  of  ILLIAC  IV  time. 

* 

At  least  300K  of  core  is  required  for  most  GLYPNIR  programs.  More 
may  be  required  for  syntactically  complex  programs. 
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a8sembly->-slmulator  process.  The  1000-card,  3-second  simulation  takes 
roughly  7  minutes  to  translate  to  PL/I,  6  minutes  to  compile,  and  30 
minutes  to  execute  on  a  360/65.^ 

It  must  be  remembered  that  the  purposes,  and  thus  the  results  of 
the  simulator  and  the  translator  are  different.  For  example,  because 
of  Internal  number  representations,  answers  via  GLYPLIT  uiav  differ  as 
early  as  the  fourth  significant  digit  from  answers  via  the  simulator. 
Also,  iiardware-oriented  features  of  GLYPNIR  are  not  translatable,  such 
as  the  ability  to  Insert  ASK  code,  the  alphameric  WAND  and  WIMP  machine 
operations,  and  the  explicit  specification  of  registers  possible  for 
efficiency.  The  restriction  to  scientific  GLYPNIR  programs  means  that 
all  of  GLYPNIR's  list  and  pointer  processing  capabilities  have  been 
left  out.  However,  these  considerations  will  not  usually  interfere 
with  the  primary  goal  of  GLYPLIT:  to  facilitate  the  debugging  of 
scientific  GLYPNIR.  (Appendix  F  summarizes  the  important  restrictions) . 

1.1  SUGGESTIONS  FOR  USING  THIS  MANUAL: 

Many  instructions  and  explanations  in  this  manual  make  sense  only 
in  the  context  of  a  GLYPNIR  program  using  the  indicated  construct.  Thus 
the  reader  should  not  be  trovibled  if  all  is  not  clear  on  the  first  read¬ 
ing.  Furthermore,  a  number  of  sections  are  Intended  as  supplements  to 
the  GLYPNIR  Programming  Manual,  auc  so  a  complete  description  of  GLYPNIR 
is  not  provided.  This  is  especially  true  of  Sec.  2,  Restrictions  and 
Differences  of  the  GLYPLIT  Subset. 

The  best  approach  for  most  new  GLYPNIR  programmers  will  be  to  read 
the  GLYPNIR  Programming  Manual  thoroughly,  read  this  manual  (especially 
noting  restrictions  and  differences  as  per  Sec.  2),  and  then  try  some¬ 
thing.  Given  the  context  of  a  user's  program,  both  manuals  will  (hope¬ 
fully)  make  sense. 


A  machine  comparable  to  the  Burroughs  6500. 

Section  2  is  numbered  to  correspond  to  the  GLYPNIR  manual,  and 
sections  for  which  no  comment  is  necessary  are  not  Included.  Thus  to 
see  if  there  are  any  translator  restrictions  for  a  particular  GLYPNIR 
construct,  the  user  may  scan  the  Sec.  2  subheadings  in  the  table  of 
contents.  If  the  item  does  not  appear,  then  no  special  precautions 
are  necessary. 
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Also  note  that  Fig.  3  of  Appendix  E  is  a  complete  example,  in¬ 
cluding  both  a  GLYPNIR  proi^ram  and  Job  Control  Language  (JCL) .  With 
minor  modifications  to  th«:  JCL  for  the  upfr's  installation,  this  ex¬ 
ample  may  be  punched  and  run  as  an  aid  to  getting  started. 

1.2  ORGANIZATION  OF  THE  REPORT 

This  report  details  the  restrictions  of  the  GLYPNIR  subset  ac¬ 
cepted  (Sec.  2)  ,  presents  the  PL/I  Input/output  and  debugging  features 
(Sec.  3) ,  describes  user  control  of  the  translator  and  insertion  of 
user-supplied  PL/I  (Sec.  4)  ,  discusses  the  IBM  360  Job  Control  Language 
necessary  to  run  the  system  (Sec.  5)  ,  and  ifescrlbes  the  translator 
output  (Sec.  6).  Several  appendixes  include  the  structure  of  the 
generated  PL/I,  PL/I  compiler  and  execution  messages,  translator  mes¬ 
sages,  and  a  summary  of  the  restrictions  of  the  GLYPNIR  subset. 


2.  RESTRICTIONS  AIH)  DIFFERENCES  OF  THE  GLYPLIT  SUBSET 

2.1  INTRODUCTION 

This  section  describes  the  restrictions  on  full  GLYPNIR  that  de¬ 
fine  the  subset  of  GLYPNIR  acceptable  to  the  GLYPLIT  translator.  The 
main  omissions  are  pointers  (and  thus  field-content  designators) ,  and 
such  hardware-oriented  features  as  alphameric  operators,  code  state¬ 
ments,  and  explicit  use  of  hardware  registers.  (See  Appendix  F  for  a 
summary. ) 

2.1.1  Numbering  of  Subsections 

In  this  seotiorij  aubaeotion  nwrbeva  oorveapond  to  numbera  in  the 
GLYPNIR  Pvogrccmming  Manual  (GPM)  [1].  For  example,  subsection  2.2.6 
corresponds  to  GPM  2.6,  and  2. 6. 3.2  corresponds  to  GPM  6.3.2.  Those 
parts  of  the  GPM  fcr  which  no  comment  is  necessary,  l.e.,  fcr  which 
there  are  no  restrictions  on  or  differences  between  GLYPNIR  and  GLYPLIT, 
are  not  Included. 

An  important  difference,  which  applies  throughout,  is  due  to  the 
different  Internal  representations  of  numbers  between  the  ILLIAC  IV 
and  the  .'60  (see  2.3  for  details). 

2.2  CODING  PROCEDURES  AND  PROGRAM  STRUCTITIE 


2.2.1  Character  Set  and  Coding  Form 

The  360  GLYPLIT  implementation  uses  the  same  character  set  as 
+ 

GLYPNIR,  with  the  following  Important  exceptions: 


GLYPNIR 

360  GLYPLIT 

USE 

[  ] 

<  >  or  ^  ! 

oubscrlpt  delimiters.  Note  that 
this  may  cause  problems  if  an 
attempt  is  made  to  use  "<"  for 
"less  than."  "LSS"  should  be 
uc.ed  Instead.  4 

X 

* 

Multiplication  symbol. 

But  punched  in  standard  360  EBCDIC  Instead  of  B6500  BCL. 

i  and  !  are  the  360  Interpretations  of  [  and  ]  punched  on  a 
Burroughs  EBCDIC  keypunch. 
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GLYPNIR 

360  GLYPLIT 

USE 

■  or  :■ 

^slgnment  statement  replacement 
operator. 

2; 

LEQ 

Relational  operator. 

ii 

GEQ 

Relational  operator. 

NEQ 

Relational  operator. 

< 

<  or  LSS 

See  [  ]  above. 

The  source  margins  for  GLYPLIT  are  defined  by  user  parameters  LC 
and  RC,  but  are  usually  defaulted  to  columns  1-72  (see  4.1.7).  No 
sequence  field  checking  Is  done. 

2.2.4  Identifiers 

Only  the  first  31  characters  of  any  Identifier  are  retained. 
(ERROR  message  48  la  generated  for  Identifiers  of  length  >  31  char¬ 
acters.)  All  of  GLYPLIT  Internally  generated  Identifiers  start  with 
the  letters  'QQ'.  Thus,  the  user  should  avoid  Identifiers  starting 
with  'QQ',  except  to  achieve  special  effects  In  user-written  PL/I  code 
(see  Sec.  4). 

2.2.5  Statements 

Statements  Input  to  GLYPLIT  may  be  split  over  several  cards.  The 
maximum  number  of  characters  permitted  between  semicolons  Is  256, 
This  count  does  not  Include  leading  and  trailing  blanks  on  any  card. 


2.2.10  Program 

If  a  label  Is  prefixed  to  the  first  BEGIN  of  the  program,  It  ap¬ 
pears  at  the  top  of  each  p  ige  of  SYSPRINT  output.  There  may  be  no  com¬ 
ments  or  PL/I  after  the  final  'END,'. 

2.3  ILLUC  IV  ARCHITECTURE  W.RSUS  360  ARCHITECTURE 

This  section  covers  Internal  number  representations. 
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number  bits 
number  slg.  digits 
decimal  range 


Exponent 

number  bits 

decimal  range  ^ 

Mantissa 

number  bits 

number  slg. 
digits 

decimal  ranges  ^ 


GLYPNIR  Type  INTEGER 

ILLIAC  IV 

sign  +  48 
14.3 

±281  474  976  710  655 

GLYPNIR  Type  REAL 
ILLIAC  IV 

15 (base  2) 

-  4933  to  4931 

sign  +  48 


360 

sign  +  31 
9.2 

±2  147  483  647 

360 

7 (base  16) 

-  79  to  75 

sign  +  24  or  56^ 

7.2  or  16.7'*' 
±5.4x10"^^  to  ±7.2x10^^ 


14.3 

±4.2x10“^^^^  to  ±5.9x10^®^^ 


2.4  BASIC  ELEMENTS  OF  THE  LANGUAGE 


2.4.1  Declarations 

Only  types  PE  INTEGER,  PE  REAL,  CU  INTEGER,  CU  REAL,  and  BOOLEAN 
(and  their  abbreviations)  are  recogiilzed  (see  2.9.1  for  special  sVi.- 
routlne  parameter  declarations  of  CNPOINT  and  PCPOINT) . 

2. 4. 2. 3  Equivalence  on  Simple  Variables.  Not  Implemented. 

2.4.4  Partial  Word  Dealgnators 
Not  Implemented. 

2. 4. 5.1  Arithmetic  Literals.  The  only  acceptable  explicit  base  specifier 
Is  '(16)',  base  sixteen,  usually  used  for  BOOLEAN  mode  patterns. 

Single  or  double  precision  as  a  user  option  (see  4.2.2). 
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2. 4. 5. 2  Alphameric  Literals.  Not  implemented. 

2.4.5. 3  Boolean  Literals.  See  4.1.3  for  effects  on  Boolean  literals 
when  #PES  4  64. 

2.5  POINTERS.  FIELD  CONTENT  DESIGNATORS.  AND  DYNAMIC  STORAGE  ALLOCATION 
Not  Implemented. 

2.6  EXPRESSIONS 

GLYPLIT  accepts  only  arithmetic  and  Boolean  expressions. 

2.6.1  Arithmetic  Expressions 

GLYPLIT  does  not  accept  <arlthmetlc  FCD>  or  <alphamerlc  expresslon> 
as  <arithmetlc  primary>. 

2.6.2  Alphameric  Expressions 
Not  implemented. 

2.6. 3. 2  Boolean  Literals.  Note  that  only  base  sixteen  '(16)'  is  legal 
as  an  explicit  base  specifier. 

2.7  ASSIGNMENT  STATEMENTS 


2.7.1  General 

Only  the  real,  integer  and  Boolean  entries  in  Table  7.1.1  in  the 
GLYPNIR  Programming  Manual  are  meaningful. 

2.8  CONTROL  STATEMENTS 


2.8.1  LOOP  Statement 

The  <lnltlal>,  <lncrement>,  and  <llmit>  values  have  permissible 
ranges  of  -2147483647  to  2147483647  in  GLYPLIT.  No  error  messages  will 
be  generated  unless  the  values  ars  outside  of  the  above  ranges.  GLYPNIR' s 
legal  ranges  are  0  to  1677216  for  <lnltlal>  and  <Ilmlt>  and  0  to  16384 


for  <lncrement>. 
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2,8.2  FOR  Statement  (Iterative) 

Not  Impleinented .  The  FOR  ALL  statement  (Gl'M  8.3)  ia  Implemented. 

2.8.7  The  Debug  Statement 
Not  Implemented. 

2.9  SUBROUTINES 


2.9.1  Description 

Subroutines  are  as  described »  except  that  (1)  the  AS  construct 
is  not  legal  and  (2)  empty  or  missing  parameters  are  not  allowed.  Note 
that  the  formal  parameters  of  the  subroutine  declaration  are  the  only 
variables  which  may  be  of  types  PCPOINT  or  CNPOINT.  These  types  are 
substitutes  for  PREAL  and  CREAL  VECTORS.  That  ia,  to  pass  on  a  real 
vector  (PE  or  CU)  to  a  subroutine,  declare  the  formal  parameter  to  be 
of  type  PCPOINT  or  CNPOINT,  and  use  the  unsubscrlpted  vector  name  as 
an  actual  parameter  In  the  GALL  statement.  Inside  the  subroutine, 
refer  £o  the  pointer  type  parameter  as  If  it  is  a  vector  in  the  usual 
way.  For  example: 

BEGIN 

PREAL  VECTOR  V[10]; 

SUBROUTINE  S (PCPOINT  A); 

BEGIN 

CINT  I; 

LOOP  1-1,1,10  DO 

A[oj  -  A[0]  +  A[I) ; 

END; 


S(V); 


END. 

Note  that  while  inside  the  subroutine  the  vector  will  always  be 
assumed  to  be  of  type  REAL.  If  an  integer  vector  is  passed  to  the  sub¬ 
routine,  it  will  be  converted  to  type  REAL  by  the  normal  parameter- 
passing  mechanism. 


Function  subroutines  may  be  of  type  PE  or  CU  REAL  or  INTEGER  or 
BOOLEAN.  GLYPLIT  prefixes  all  function  names  with  the  letters  'SS'. 

See  2.9.3,  4.2.2,  A. 3,  B.l,  and  B.2  for  the  effects  of  this. 

2.9.3  Separately  Compiled  Subroutines 

This  is  a  translator  feoture  not  yet  available  in  GLYPNIR.  Its 
purpose  is  to  allow  subroutines  from  a  GLYPNIR  program  to  be  translated 
and  compiled  separately,  and  then  link  edited  and  run  together  (see  5.3 
for  link  edit  JCL  information).  There  are  at  least  two  possible  reasons 
for  using  this  option.  First,  the  current  PL/ I  implementation  allows 
only  255  Iterative  DO-END  or  BEGIN-END  blocks  in  one  compilation.  PL/l 
Issues  TERMINAL  ERROR  IEM0071I  message  if  this  limit  is  executed,  as  it 
m.y  well  be  for  GLYPNIR  programs  of  mire  than  a  few  hundred  cards.  Thus, 
the  GLYPNIR  program  must  be  broken  into  two  or  nwre  parts,  which  may  then 
be  translated  and  compiled  separately.  A  second  reason  for  using  this 
option  is  reduced  cost,  achieved  by  eliminating  the  need  to  retranslate 
and  recompile  sections  of  the  code  that  are  not  changing. 

The  only  convenient  way  to  allow  separate  compilation  is  to  have 
a  main  program,  and  one  or  more  separate  subroutines.  Two  problems  must 
be  solved:  the  main  program  must  know  about  the  subroutine  (accomplished 
with  the  %%C  SUBR  option) ,  and  the  separate  parts  must  be  able  to  com¬ 
municate  (accomplished  via  parameters  and/or  the  %%C  EXTERNAL  option). 
Figures  2.1  to  2.3  (and  following  notes)  show  a  subroutine  within  a  main 
program,  and  then  the  satae  subroutine  and  main  program  ready  to  be  trans¬ 
lated  and  compiled  separately. 

Note  the  following: 

1.  In  Fig.  2.1,  the  P2  inside  the  subroutine  is  the  same  as  the 
P2  outside  the  subroutine  because  P2  was  not  redeclared  in  the  sub¬ 
routine.  Thus,  communication  is  established  through  the  global  variable 
P2,  and  through  the  parameter  PI. 

2.  In  Fig.  2.2,  the  main  routine  is  made  aware  of  the  subroutine 
via  the  %%C  SUBR  card,  followed  by  the  subroutine  declaration,  but  with¬ 
out  the  body  of  the  subroutine. 

3.  In  Fig.  2.3,  just  the  subroutine  is  input  to  the  translator. 

It  must  now  end  with  "END."  Instead  of  "END;",  because  all  input  to  the 
translator  is  terminated  by  "END.". 


Together: 


BEGIN 
PREAL  P2; 

SUBROUl’INE  S (PREAL  PI); 
BEGIN  PREAL  A; 


P2  -  PI  +  A; 


END; 


END. 

Fig.  2.1— Main  Program  and  Subroutine  Together 

Separate:  Figures  2.2  and  2.3  are  each  to  be  presented  to  the 
translator-compiler  separately. 


BEGIN 

XXC  EXTERNAL 
PREAL  P2; 

XXC  SUBR 

SUBROUTINE  S (PREAL  PI) ; 


S(...); 


END. 


SUBROUTINE  S (PREAL  PI); 
BEGIN  PREAL  A; 

XXC  EXTERNAL 
PREAL  P2; 


P2  -  PI  +  A; 


END. 


Fig.  2.2“Ma1n  Program 


Fig.  2.3— Subroutine 


4.  The  global  variable  P2  is  given  the  EXTERNAL  attribute  via 
the  nc  EXTERNAL  card  In  both  Fig.  2.2  and  Fig.  2.3.  This  makes  it 
common  to  all  routines  in  which  it  is  made  external.  Thus,  communi¬ 
cation  is  still  through  the  parameter  PI,  and  the  global  variable  P2. 

5.  All  variables  used  in  the  subroutine  must  be  In  one  of  three 
classes : 

a.  They  may  be  parameters  passed  through  the  calling 
sequence,  e.g.,  PI; 

b.  They  may  be  global  variables  known  to  several  routines 
via  the  external  attribute,  e.g.,  P2; 

c.  Or  they  may  be  completely  Internal  to  the  subroutine, 
e.g.,  A. 

6.  Even  If  no  parameters  are  present,  the  %%C  SUBR  card  Is  still 
required  in  Fig.  2.2. 

7.  See  5.3  for  JCL  information.  Sections  4.2.2  and  4.2.4  detail 
the  %%C  SUBR  and  EXTERNAL  option. 

8.  PL/ I  generates  error  message  IEM2867I  (see  B.2)  for  separately- 
compiled  subroutine  or  external  variable  names  of  more  than  seven  char¬ 
acters.  To  avoid  this,  limit  all  separately-compiled  subroutine  or 
external  variable  names  to  seven  characters  and,  because  GLYPLIT  pre¬ 
fixes  all  function  subroutine  names  with  'SS',  limit  all  separately- 
compiled  function  subroutine  names  to  five  characters. 

2.10  SYSTEM  SUBROUTINES 

2.10.1  SHIFT  and  REVOLVE 

The  <value>  to  be  shifted  or  revolved  must  be  a  Boolean  expression, 
e.g.,  the  word  I^DE. 

2.10.2  Route 

As  noted  in  the  GPM,  the  <mode  pattern>  may  be  any  Boolean  expres¬ 
sion,  or  empty.  Even  though  GLYPLIT  accepts  either,  only  the  eeoond 
aasej  empty^  is  oovveatly  implemented.  Any  Boolean  expression  is 
Ignored.  GLYPLIT  translates  all  routes  as  demonstrated  by  the  follow¬ 
ing  example: 


PREAL  P1,P2,PJ,P4; 

PI  =■  RTL(1,,P2+P3)  P4; 

becomes 

DCL  (Pi,P2,P3,P4)(0:63)  FLOAT  BIN; 

DO  QQ-0  to  63;  IF  MODE  (QQ)  THEN  DO; 

Pl(QQ)  -  P2(MOD(QQ+l,63))  +  P3(MOD(QQ+l ,63) )  +  P4(Q0); 

Thus,  the  expression  is  evaluated  in  the  source  PE  only  if  the  mode  is 
true  in  the  destination  PE.  This  is  exactly  what  GLYPNIR  does  if  the 
<mode  pattern>  is  empty. 

The  purpose  of  a  non-empty  mode  pattern  is  to  prevent  evaluation 
of  the  expression  in  certain  source  PEs,  even  if  the  destination  PE  is 
true.  This  results  in  an  undefined  value  in  those  destination  PEs, 
but  this  is  presumably  to  be  changed  in  a  subsequent  statement.  An 
example  might  be : 

PI  =  RTL(1,P3  NEQ  0,  P2/P3) 

IF  RTL(1,,P3)  EQL  0  THEN  PI  =  P2; 

Unfortunately,  the  first  statement,  translated  by  GLYPLIT,  could  result 
in  a  ZERODIVIDE  error,  because  P2/P3  might  be  evaluated  in  a  PE,  where 
P3  is  zero.  An  acceptable  alternative  would  be: 

IF  RTL(1,,P3)  NEQ  0  THEN  P1=RTL(1, ,P2/P3) 

ELSE  P1-P2; 

(Note:  If  the  current  mode  pattern  is  all  true,  then  "MODE"  is 
frequently  used  as  the  routing  <mode  pattern>  because  GLYPNIR  gener¬ 
ates  the  most  optimal  code.  But  no  problem  can  result  even  though 
GLYPLIT  ignores  this,  because  the  mode  pattern  is  all  true.) 

2.10.4  ALPHA 

Not  implemented. 

2.10.5  BOOLEAN 

The  act’ial  parameter  for  the  BOOLEAN  function  must  be  a  hexadecimal 
literal,  e.g.,  B00LEAN(0FFF(16)) . 
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2.10.6-2.10.8  Trigonometric,  Squaie  Root,  Natural  Log, 
and  Exponentiation 

These  functions  are  automatically  available  in  GLYPLIT.  In  other 
words,  the  instructions  of  GPM  10.6  for  including  ASK  assembly  language 
subroutines  must  be  Ignored.  No  declarations  of  any  kind  are  necessary 
or  allowed  for  SIN,  COS,  TAN,  COT,  ATAN,  SQRT,  LN,  or  EXP. 

2.11  INPUT/OTITPUT  STATEMENTS 

Not  implemented.  See  4.2  for  GLYPLIT  I/O  via  PL/I. 

2.12  EXPLICIT  USE  OF  HARDWARE  REGISTERS  ANL  ASSEMBLY  LANGUAGE 
Not  Implemented. 

2.C  DIAGNOSTIC  MESSAGES 
See  Appendix  C. 

2.D  OPERATION  MANUAL 

All  cards  starting  with  the  '$'  in  column  1  are  ignored  by  GLYPLIT, 
except  for  listing.  See  Secs.  4  and  5  for  GLYPLIT  operation. 
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3.  PL/ 1  INPUT/OUTPUl'  AND  DEBUGGING  FEATURES 

3.1  INTRODUCTION 

The  ability  to  mix  PL/I  statements  freely  with  the  GLYPNIR  to  be 
debugged  is  a  useful  feature  of  the  translator;  however,  it  does  re¬ 
quire  some  user  knowledge  of  PL/I.  The  essentials  of  PL/I's  I/O  and 
debugging  features  are  covered  here,  but  for  complex  I/O,  variable 
setting,  or  other  PL/I  procedures  the  user  is  referred  to  the  IBM  PL/I 
manuals  [2-3]. 

3.2  MIXING  OF  PL/I  AND  GLYPNIR;  THE  %%B  OPTION 

All  PL/I  statements  must  be  placed  on  %%  cards  (%%  in  columns  1 
and  2,  and  possibly  a  "B"  in  column  3).  These  will  appear  as  comments 
to  GLYPNIR,  and  will  be  passed  directly  to  the  PL/ I  file  by  the  trans¬ 
lator  after  stripping  off  the  %%  (or  %%B).  PL/I  statements  are  termi¬ 
nated  by  semicolons  Several  statements  may  be  placed  on  one 

(japd  or  one  statement  contiviued  on  several  cards,  much  as  in  GLYPNIR. 

The  %%B  Option:  the  major  task  of  the  translator  is  to  "put  in 
the  inner  DO  loops".  Thus  the  GLYPNIR 

PREAL  PI,  P2,  P3; 

PI  -  P2  +  P3; 

must  be  changed  to  the  PL/I 

DCL(P1,P2,P3)  (0:63)  FLOAT  BIN; 

DO  QQ  -  0  TO  63; 

IF  MODE(QQ)  THEN  DO; 

Pl(QQ)  -  P2(QQ)  +  P3(QQ); 

END;  END; 

The  %%B  option  is  used  to  control  the  location  of  the  user-sup¬ 
plied  PL/I.  If  the  "B"  is  in  column  3,  i.e.,  "%%B",  then  the  PL/I 
on  the  card  is  guaranteed  to  be  outside  (to  Break)  any  current  gen¬ 
erated  DO  loop.  If  the  "B"  is  not  present,  the  PL/I  may  be  inside  a 
DO  loop,  if  one  is  currently  open.  There  will  be  a  current  open  DO 
loop  if  one  has  been  started  by  the  appearance  cf  a  PE  or  BOOLEAN 
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left-hand-slde  assignment  statement,  and  If  all  subsequent  statements 
have  been  PE  or  Boolean  assignment  statements  and  have  not  Involved 
certain  types  of  routing.  That  Is,  assignment  statements  are  collected 
Into  a  common  DO  until  a  non-conforming  statement  ''.uses  the  DO  to  be 
broken  (closed) . 

There  are  also  other  reasons  for  closing  a  DO,  and  It  Is  admittedly 
harder  for  a  user  to  be  sure  his  PL/I  will  end  up  inside  a  DO.  However, 
this  Is  not  the  common  case — being  outside  the  DO  Is  usually  deslrea. 
This  Is  guaranteed  by  a  %%B.  The  user  may  of  course  check  the  location 
of  bis  PL/I  by  reading  the  PL/I  on  the  SYSPRINT  file  from  the  PL/I 
compiler. 

Note  that  If  user  PL/I  Is  to  be  Included  In  a  generated  DO  for 
special  effects,  then  the  DO  loop  Index,  always  called  QQ,  may  be  used. 
See  Appendix  A  for  other  naming  conventions  and  more  Information  on 
DO  location. 

3.3  PL/I  INPUT/OUTPUT 

The  following  Is  a  brief  Introduction,  but  should  allow  the  In¬ 
experienced  user  to  get  started  (jxist  try  something).  Further  details 
are  In  Ref.  2. 

All  GLYPNIR  I/O  must  be  conducted  via  PL/I  I/O  statements.  These 
are  GET  and  PUT  for  stream  reads  and  writes  (corresponds  somewhat  to 
FORTRAN  formatted  I/O) ,  and  READ  and  WRITE  for  record-oriented  I/O 
(corresponds  somewhat  to  FORTRAN  binary  or  unformatted  I/O) . 

VJhen  reading/writing  arrays,  note  that  FL/I  stores  arrays  In 
opposite  order  to  FORTRAN,  l.e.,  the  rightmost  subscript  varies  fastest 
In  PL/I. 


READ  I 

> FILE  (file-name)  INTO(one-varlable-name) ; 
WRITE  i 


The  READ/WRITE  syntax  Is  fairly  self-evident.  The  length  of  the 
variable  In  bytes  should  usually  be  the  same  as  the  record  length  (LRECL) 
of  the  DCB  parameter  on  the  DD  JCL  card  defining  the  file. 
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)  i  DATA  (optional-list-of-variables) 

p„_  ?  FILE (file-name)  <  LIST  (llst-of-variables) 

)  (edit  (list-of-variables) (forwat  specification) 

The  '  FILE  (file-name) '  is  optional,  although  if  omitte*:\  a  warning 

message  will  be  generated  during  compilation.  If  it  is  fitted,  file 
SYSIN  will  be  assumed  for  a  GET,  and  file  SYSPRINT  aseuv;i  for  a  PUT. 

The  format-specification  applies  to  EDIT  only.  Tne  elements  of 
the  list  of  variables  must  be  separated  by  commas.  Each  element  may 
be  a  simple  varlaole  name,  an  array  name,  a  repetitive  specification 
for  arrays  (see  below),  or  for  output,  a  constant.  Character  constants 
are  contained  by  single  quote  marks  (')  and  may  be  split  across  cards 
with  column  72  and  column  1  being  taken  as  contiguous  (although  note 
that  the  %%  required  in  columns  1  and  2  will  become  blanks  in  the  nldst 
of  the  constant).  A  repetitive  array  specification  is  of  the  form 

(a(l) ,  DO  10  subscript, 

((a(i»j)»  DO  TO  I2) ,  DO  TO  j2)  for  two  subscripts, 

etc.  (Of  course,  1  and  j  may  be  reversed  for  the  opposite  I/O  order.) 

LIST-dlrected  I/O  transmits  just  the  elements.  For  input  the  ele¬ 
ments  must  be  constants  separated  by  commas  or  blanks;  for  output  they 
will  be  separated  by  blanks  and  formatted  automatically,  according  to 
their  attributes. 

DATA-dlrected  I/O  transmits  the  variable  names  as  well  as  the 
v>  '.ues  (like  NAMELIST  I/O  in  FORTRAN)  and  is  extremely  useful  for  de¬ 
bugging  output.  For  input,  the  form  is  variable-name  *  constant, 
separated  by  commas  and/or  blanks.  The  last  element  of  the  list  must 
be  followed  by  a  semicolon.  The  list-of-var Tables  is  optional:  on 
input,  the  names  in  the  input  determine  the  variables  transmitted,  and 
on  output  all  variables  known  in  the  block  will  be  transmitted  if  no 
list  is  given. 

EDIT-directed  output  is  m.>st  like  FORTRAN  formatted  I/O  and  re¬ 
quires  the  format-specification.  Format  Items  are  separated  by  commas 
and  may  be  grouped  by  placing  several  in  pakrentheses.  A  single  item 
or  group  may  be  repeated  by  preceding  it  with  a  constant  or  variable 
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followed  by  a 

blank. 

Some 

legal  format  items  and  their  FORTRAN  equiv 

alents  follow: 

PL/ 1 

FORTRAN 

Meaning 

F(w) 

Iw 

Integer  In  field  width  w. 

F(w,d) 

Fw.d 

Floating  In  field  width  w  with  d  digits 
to  right  of  decimal  point. 

E(w,d) 

Ew.  d 

Scientific  notation  in  field  width  w  with 
d  digits  to  right  of  decimal  point. 

A(v) 

Aw 

Characters  In  field  width  w.  If  w  not 
supplied,  length  of  element  being  trans¬ 
mitted  determines  length . 

X(w) 

wX 

w  spaces. 

SKIP(n) 

//... 

/ 

✓ 

Skip  n  records — see  below. 

PAGE 

n 

IHl 

Skip  CO  top  of. page. 

Note  that  there  ie  no  "Hollerith"  format.  To  output  a  character  constant 
in  PL/ I,  the  constant  Is  placed  in  quotes  in  the  variable  list  and  an  A 
format  specification  Is  used  (usually  without  the  field  width  w) . 

SKIP  and  PAGE  may  be  added  to  any  GET/PUT  statement  (except  PAGE 
and  GET  are  not  legal  together).  The  following  example  Illustrates  much 
of  the  above: 

PUT  FILE(SYS?RINT)  EDIT('TWO  INTEGERS ,I ,J FOUR  REALS:', 
A,B,C,D)(A,F(5).F(10),SKIP(2),A,4  F(10,5) )PAGE; 

LIST-,  DATA-,  and  EDIT-dlrected  I/O  is  called  atveam  I/O  because 
little  cognizance  Is  taken  of  card,  line,  or  other  record  boundaries. 
Successive  PUT  statements  will  continue  on  the  same  line  until  there  Is 
no  more  room,  or  until  a  SKIP  or  PAGE  specification  Is  encountered. 
Successive  GET  statements  will  continue  reading  from  the  same  card  until 
no  more  columns  remain,  or  until  a  SKIP  skips  to  the  start  of  the  next 
card. 


3.4  PL/I  DEBUGGING  FEATURES 


The  principal  debugging  aid  In  PL/I  (besides  easy  LIST-  and  DATA- 
dlrected  I/O — see  3.3)  is  the  condition  prefix.  It  looks  somewhat  like 
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a  GLYPNIR  label  with  the  form 


(a,b,c, • • .)  s 

and  may  be  placed  on  any  statement  including  a  BEGIN-END  or  PROCEDURE- 
END  block.  On  a  block,  a  condition  applies  to  all  statements  within 
the  block,  except  that  it  may  be  negated  for  a  statement  (or  block) 
within  the  block  by  placing  the  opposite  condition  on  that  statement 
(or  block).  On  an  IF  statement,  the  condition  applies  only  to  the 
Boolean  expression  of  the  IF.  Similarly,  a  condition  on  an  iterative 
DO  (generated  as  a  result  of  LOOP  and  FOR  statements)  applies  only  to 
expressions  in  the  DO  statement  (J,k,  and  m  in  DO  l»j  TO  k  BY  m)  and 
not  to  statements  contained  within  the  DO-END  group. 

To  cause  a  condition  prefix  to  apply  to  a  group  of  statements , 
enclose  the  group  in  a  BEGIN-END  block  and  place  the  prefix  on  the 
BEGIN.  Condition  prefixes  may  also  appear  on  PROCEDURE  statementu  (be¬ 
fore  the  procedure  name)  to  apply  to  all  statements  in  the  procedure. 
Thus,  to  have  a  condition  prefix  apply  to  a  whole  GLYPNIR  program,  make 
it  the  very  first  card  presented  to  the  translator  (with  %Z  in  columns 
1  and  2 )  . 

If  a  condition  prefix  occurs  on  a  labeled  statement  (or  procedure), 
it  must  precede  the  label  (or  procedure  na  2) ,  e.g., 

%%(NOOFL,CHECK(A,B)); 

LABELl;  BEGIN... 

The  content  of  the  condition  prefix  is  a  list  selected  for  the 
following  possibilities  (there  are  others  described  in  the  PL/I  manual 
[2],  but  these  should  be  the  most  useful  for  a  GLYPLIT  user).  All  con¬ 
ditions  may  be  preceded  by  "NO"  to  negate  them.  The  conditions  are 
shown  with  their  defaults,  l.e.,  with  or  without  the  NO  as  assumed  by 
the  compiler.  Also  shown  are  the  acceptable  abbreviation  and  the  stan¬ 
dard  system  action. 

Condition  Abbr .  Meaning 

FIXEDOVERFLOW  FOFL  Occurs  when  an  Integer  exceeds  the 

maximum  shown  in  2.3.  System 
action'  terminate. 


Condition 


Abbr. 


Meaning 


0VE.1FL0W 

UNDERFLOW 

2ERUDIVIDE 

NOSUBSCRIPTRANGE 

CHECK(a,b,c. . .) 


OFL  Occurs  when  the  magnitude  of  a  real 

number  exceeds  the  maximum  shown  in 
2.3  (approximately  7.2x10^^).  System 
action:  terminate. 

UFL  Occurs  when  the  magnitude  of  a  real 

number  is  less  than  the  minimum  shown 
in  2.3  (approximately  5.4x10"^^). 

System  action:  set  result  to  0,  print 
message (  and  continue. 

ZDIV  Occurs  when  attempt  is  made  to  divide 

by  0.  System  action:  terminate. 

NOSUBRG  Occurs  when  attempt  is  made  to  use  a 

subscript  out  of  the  range  of  an  array. 
System  action:  terminate.  This  can 
be  a  useful  debugging  aid,  but  because 
of  its  great  expense  (may  more  than 
double  execution  time)  it  is  normally 
not  enabled. 

The  most  important  of  the  PL/I  debug¬ 
ging  options.  a,b,c...  represents  a 
list  of  names  which  may  be  variable 
names  (including  unsubs cripted  array 
nar.es),  entry  (procedure)  names,  and 
statement  labels.  For  entry  nrmes  and 
labels,  the  name  will  be  automaticaMy 
printed  each  time  it  is  invoked  or 
passed.  For  variables  (which  may  not 
be  parameters) ,  the  variable  name  and 
its  new  value  will  be  printed  each  time 
it  is  set,  e.g.,  by  appearing  as  the 
left-hanc  side  of  an  assignment  state¬ 
ment,  by  input,  or  by  being  the  con¬ 
trolled  variable  of  an  iterative  DO 
(the  result  of  LOOP  and  FOR  statements, 
etc.)  . 

Two  unfortunate  notes  for  CHECK: 

o  CHECK  may  appear  only  on  a  BEGIN- 
END  or  PROCEDURE  bloci.. 

o  If  an  array  name  is  CHECKed,  the 
whole  opray  will  be  printed  every- 
time  any  element  is  changed.  Ex¬ 
ample:  assume  a  PREAL  A,  which 
will  become  an  array  of  length  64 
words  in  the  PL/I.  The  statement 
"A  =  1"  will  require  a  DO  loop  in 
the  PL/I  to  set  each  of  the  64 
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Cot.illtion 


Abbr.  Meaning; 

values  to  1.  If  A  is  being  checked, 
the  whole  array  will  be  printed 
6A  times,  once  for  each  time 
through  the  DO  loop. 
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4.  USER  CONTROL  OPTIONS  DURING  TRANSLATION 


There  are  two  classes  of  options:  JCL  FARM  options,  and  In-line 
control  options . 

4.1  JCL  FARM  OPTIONS 

The  user  supplies  these  options  on  the  360  JCL  EXEC  statement 
for  the  GLYPLIT  execution  step  In  the  form  FARM  =  'list',  and  apply 
throughout  a  translation.  They  help  specify  either  the  Input  format 
or,  more  frequently,  the  output  format.  Defaults,  shown  below  In 
parentheses,  are  supplied  for  all  options.  See  also  5.1  for  details 
of  FARM  syntax,  and  Appendix  D  for  a  summary. 

4.1.1  //FES — Number  of  Processing  Elements  (Default  ■  64) 

This  Is  one  of  the  more  Important  options.  It  specifies  how  many 
PEs  the  generated  PL/I  code  should  simulate.  Any  number  from  1  to  999 
is  legal.  For  fast  execution  of  the  generated  code,  debugging  may 
often  be  conducted  using  only  a  few  PEs.  Alternatively,  for  duplica¬ 
ting  results  of  existing  codes,  some  number  of  PEs  other  than  64  may 
be  useful  (e.g. ,  44  or  100).  With  most  "scientific"  GLYPNIR  programs, 
few  other  changes  will  be  necessary  if  #PES  Is  changed.  In  particular, 
processes  depending  on  the  number  of  PEs  and  Boolean  constants  may  cause 
problems  {,866  4,1,8  foT  cotfvn6Ti't8  on  Boo'l6Ccn  oonB’ton'ts  ifFES  ^  64), 

4.1.2  GLY—Control  of  GLYPNIR  Output  (Default  -  1) 

If  GLY  -  1,  list  the  GLYPNIR  Input  only  on  the  SYSPRINT  file. 

If  GLY  -  2,  output  the  GLYPNIR  Input  only  as  PL/I  comments  on  the 
PLIN  file. 

If  GLY  -  3,  output  the  GLYPNIR  to  both  files. 

See  also  the  next  parameter. 

4.1.3  PLl— Control  of  Generated  PL/ I  Output  (Default  -  2) 

If  PLl  ■  1,  list  the  generated  PL/I  only  on  the  SYSPRINT  file. 

If  PLl  -  2,  output  the  generated  PL/I  only  to  file  PLIN  (pre¬ 
sumably  for  Input  to  the  PL/I  compiler). 
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If  PLl  »  3,  output  the  PL/I  to  both  files. 

The  most  useful  combinations  of  GLY  and  PLl  are  the  defaults 
(GLYPNIR  on  SYSPRINT,  PL/l  on  PLIN)  If  the  PL/I  does  not  need  to  be 
looked  at,  or  GLY  -  3  and  PLl  -  2  (GLYPNIR  on  S7SPRINT,  and  GLYPNIR 
and  PL/l  mixed  on  PLIN)  if  the  PL/I  does  need  to  be  looked  at. 

4.1.4  PAGES — iaximum  Number  of  Pages  Allowed  (Default  ■  50) 

This  par/i.meter,  like  MSGS,  is  Intended  to  prevent  an  error  from 
generating  reams  of  useless  output. 

4.1.5  MSGS — Maximum  Number  of  Messages  Allowed  (Default  *50) 

This  parameter  option  prevents  some  runaway  translator  or  user 
error  from  generating  useless  error  message  output. 

4.1.6  MSG— Minimum  Significant  Message  Level  (Default  ■  1) 

Messages  are  classed  into  four  levels;  1— WARNING,  2— ERROR, 

3 — SEVERE,  and  4— TERMINAL.  This  parameter  specifies  the  minimum 
level  for  which  messages  should  be  printed.  Messages  in  a  level  be¬ 
low  MSG  are  neither  printed  nor  do  they  contribute  toward  the  MSGS 
count  (see  4,1.5).  The  level  of  each  message  is  printed  with  it  and 
is  also  noted  in  Appendix  C. 

4.1.7  LC  (Left  Column),  RC  (Right  Column),  and  CC  (Carriage  Control) — 
Source  Card  Margin  Control  (Defaults  “  1,  72,  0  respectively) 

Normally  GLYPNIR  input  should  be  in  columns  1-72,  with  columns 
73-80  Ignored,  except  for  listing;  however,  special  purposes  may  re¬ 
quire  different  margins.  If  so,  LC  may  be  set  to  the  leftmost  column 
to  bij  considered,  and  RC  to  the  right.  In  addition,  CC  may  be  set  to 
a  column  to  be  scanned  for  printer  carriage  control  as  follows: 

Contents  of  Column  CC  Action 


1 

0  (zero) 


Skip  to  top  of  page 
Double  space 
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Contents  of  Column  CC 


Action 


-  (minus) 

+  (plus) 
Anything  else 


Triple  space 
No  space 
Single  space 


Note  that  the  GLYPNIR  compiler  does  not  support  these  options. 
LC.  RC,  and  CC  must  obey  the  relations 


1  s  LC,RC,CC  s;  80 
LC  <  RC 

CC  <  LC  or  CC  >  RC. 


All  referenaea  to  aolurrma  1  and  72  throughout  this  nrxnual  should 
be  interpreted  as  referring  to  columns  LC  and  RC^  respectively . 


4.1.8  BCRC — Boolean  Constant  Repeat  Count  (Default  ■  1) 

This  section  discusses  the  treatment  of  Boolean  h-ix  constants  by 
GLYPLIT. 

Define  n  as  being  the  number  of  bits  represented  by  a  hex  constant; 
thus,  n  -  the  number  of  hex  characters  In  the  constant  ^  4.  Note  that 
n  is  aluaya  a  multiple  of  4,  although  it?ES  need  not  be.  Thus  n  may  vary 
from  4  (1  hex  character)  to  64  (16  characters).  The  problem  Is  to  map 
the  n  bits  represented  by  the  constant  Into  the  #PES  PEs.  There  are 
three  cases. 

4. 1.8.1  #PES  -  64.  This  Is  the  normal  GLYPUIR  case.  If  n  -  64, 
the  n  bits  map  exactly  left  to  right  Into  PEs  0  to  63. 

If  n  <  64,  then  the  n  bits  map  Into  the  n  rightmost  PEs,  and  the 
leftmo«5t  64  -  n  PEs  get  zeros. 


n  bits 


64  PEs 


Fig.  4.1-#PES  -  64 
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4 « 1,8. 2  #PES  <  64.  If  n  ^  //PES,  the  n  bits  map  into  the  right¬ 
most  n  PEs  and  the  leftmost  //PES  -  n  PEs  get  zeros. 

If  n  >  tfPES,  then  the  leftmost  //PES/2  bits  map  into  the  leftmost 
#PES/2  PEs,  and  the  rightmost  t?ES/2  bits  will  map  into  the  rightmost 
#PES/2  PEs.  (If  #PES  is  odd,  then  the  extra  bit  is  included  on  the 
left.)  In  other  words,  the  n  -  //PES  middle  bits  are  Ignored. 

n  bits 


//PES  FEs 


Fig.  4.2-#PES  <  64 

4, 1.8. 3  #PES  >  64.  If  n  <  64,  the  n  bits  map  into  the  rightmost 
n  PEs,  and  the  leftmost  //PES  -  n  PEs  g^  t  zeros. 

If  n  -  64,  then  the  leftmost  32  bits  map  into  PEs  0  to, 31,  the 
rightmost  32  bits  map  into  the  rightmost  PEs,  and  the  middle  PEs  are 
filled  hy  repeating  bits  33-BCRC  through  32  as  often  as  necessary. 

That  is,  the  rightmost  BCRC  bits  of  the  leftmost  32  bits  are  repeated 
to  fill  the  middle. 


n  <  64 


32nd  bit 

+ 


10  •••  1010  •••  1 


n  -  64,  BCRC  -  3,  //PES  -  72 


//PES  PEs 


Fig.  4.3— #PES  >  64 
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4. 1.8. 4  User-Supplied  Interpretation  of  Booleai\  Constanta.  If 
the  actions  described  above  for  //PES  j*  64  are  Inadequate,  then  there 
are  two  alternate  approaches  a  user  may  take.  Whenever  a  Boolean  con¬ 
stant  appears,  It  Is  replaced  by  a  QQBCx  variable,  e.g. ,  MODE  -  BOOLEAN 
(ny(16))  becomes  MODE(QQ)  -  QQBCl(QQ)  within  a  DO  loop.  The  Boolean 
constant  variables  are  Initialized  via  the  following  declaration: 

DCL  QQBCx  (0:63)  BlT(l)  INIT  CALL  QQBCI (QQBCx, 'he' ) ; 

"x"  Is  an  Integer  to  form  a  unique  name,  and  'he'  Is  the  actual  hex 
constant  character  string  In  quotes.  Then,  on  entry  to  the  program, 

PL/I  automatically  calls  the  procedure  QQBCI  once  for  each  declaration, 
which  Initializes  the  variable  'QQBCx'  to  the  hex  string  'he',  as  de¬ 
scribed  In  4. 1.8.1- '>.1.8. 3.  (The  QQBCI  procedure  Is  contained  In  the 
GLYPLIT  execution  library-card  15  of  5.2.)  A  group  of  ten  of  these 
declarations  Is  generated  for  every  ten  unique  Boolean  constants  en¬ 
countered,  with  a  final  group  (the  only  group  If  there  are  no  more  than 
ten  In  the  program)  occurring  at  the  end  of  the  generated  code. 

The  first  alternative  Is  to  make  the  user  parameter  BCRC  -  0.  In 
this  case,  no  declaration  for  Boolean  constants  will  be  generated,  al¬ 
though  each  unique  Boolean  constant  will  still  be  replaced  by  a  variable 
of  the  form  QQBCx.  Thus  the  user  Is  expected  to  declare  and  Initialize 
all  the  QQBCx  variables  generated  via  user-written  FL/I. 

A  second  alternative  Is  for  the  ’laer  to  supply  his  own  routine 
called  QQBCI.  It  should  be  of  the  following  form: 

QQBCI:  PROCEDURE (BC, LITERAL) ; 

DCL  BC(0:n)  BIT(l),  LITERAL  CHAR(16)  VAR; 


END; 


where  n  ■  #PES  -  1. 

Because  the  literal  will  be  passed  exactly  as  presented  by  the 
user  In  his  GLYPNIR  Input,  the  user  may  simply  make  his  Boolean 
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constants  numbers,  0,^,,  *1*,  *2',  etc.,  and  use  LITERAL  as  an  index 
Into  a  table  containing  the  desired  initial  values.  An  example  follows 
for  Boolean  constants  of  3  bits. 

QQBCI:  PROCEDURE (BC,  LITERAL); 

DCL  BC(0:2)  BIT(l),  LITERAL  CHAR(16)  VAR; 

DCL  TBL(0:2,2)  BIT(l)  INIT('010' , '101')  ; 

BC  -  TBL(*, LITERAL); 

END 

The  assignment  statement  is  an  array  assignment:  the  means 
all  eleirients  in  the  range  of  that  dimension.  PL/I  automatically  con¬ 
verts  the  character  contents  of  LITERAL  to  Integer  if  the  contents  are 
a  number. 

Thus,  if  the  user  supplies  this  routine,  and  does  not  give  BCRC  ■  0 
(which  would  ca’ise  no  declarations  to  be  generated),  then  the  statement 

B1  -  B00LEAN(1(16))  OR  B00LEAN(2 (16) ) ; 
is  translated  as  (assuming  #PES  -  3) 

DO  QQ  -  0  TO  2; 

Bl(QQ)  -  QQBCl(QQ)  [  QQBC2(QQ); 

END; 

and  causes  the  declarations 

DCL  QQ3C1(0:2)  BIT(l)  INIT  CALL  QQBCI(QQBC1 , ' 1' ) ; 

DCL  QQBC2(0;2)  BIT(l)  INIT  CALL  QQBCI(QQBC2 , ' 2 ' ) ; 

to  be  generated.  Then  on  entry  to  the  main  program,  QQBCI  would  be 
called  twice  and  QQBCI  and  QQBC2  would  be  Initialized  to  '010'  and 
'101'. 

4.1.9  LINES — Number  of  Lines  per  Page  of  SYSPRINT  Output  (Default  “  60) 
Useful  for  installations  with  short  paper. 
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4.2  CONTROL  OPTIONS 

Tlliese  options  are  placed  on  XXC  cards  and  mixed  with  the  GLYPNIR 
Input.  Unlike  FARM  options,  which  apply  to  a  whole  translation,  these 
options  normally  apply  to  only  the  next  statement  or  to  a  range  of 
ctatements . 

4.2.1  XXC  Cards 

All  In-llae  GLYPLIT  control  options  must  be  placed  on  cards  start¬ 
ing  with  %%C  In  columns  1,  2,  and  3.  (These  cards  will  be  comments  to 
GLYPNIR.)  Several  options  may  be  placed  on  one  card  but  the  option 
words  START  and  END  may  not  both  appear  on  one  card.  All  option  words 
may  appear  In  any  order  separated  by  any  number  of  blanks  or  any  other 
aharaatere ,  Note  that  this  means  that  comment  cards  starting  with  XXC 
should  be  avoided  because  they  will  oe  misinterpreted  as  option  cards. 
(See  3.2  for  discussion  of  7.X  cards  for  PL/ 1.) 

4.2.2  EXTERNAL  Declarations 

Declarations  may  be  made  to  have  the  PL/I  external  attribute  by 
use  of  the  XXC  EXTERNAL  card.  This  card  should  precede  a  GLYPNIR  de¬ 
claration  for  which  the  external  PL/I  declaration  Is  to  be  generated. 

The  option  normally  applies  only  to  the  following  declaration.  If  the 
option  word  "START"  Is  also  on  the  card,  however,  all  following  declara¬ 
tions  will  be  made  external  until  a  %%C  option  card  with  the  words 
"EXTERNAL"  and  "END"  appears. 

External  declarations  and  subroutine  parameters  are  the  only  easy 
methods  of  Inter-subroutlne  communication  for  ae'parately  aompiled  pro¬ 
cedures  In  PL/I.  The  external  attribute  takes  the  pl».c  j  of  COMMON  In 
FORTRAN.  (See  2.9.3  for  separately  compiled  procedures.) 

Note  that  PL/I  generates  an  error  message  (see  B.2)  for  separately- 
compiled  subroutine  or  external  variable  names  of  more  than  seven  char¬ 
acters.  To  avoid  this,  limit  all  separately-compiled  subroutine  or 
external  variable  names  to  seven  characters  and,  because  GLYPLIT  pre¬ 
fixes  all  function  subroutine  names  with  'SS',  limit  all  separately- 
compiled  function  subroutine  names  to  five  characters. 
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In  conformance  with  a  recently  issued  ILLIAC  IV  Document  [6),  COMMON 
and  ENDCOMMON  statements  may  be  used  instead  of  %%C  START  EXTERNAL  and 
%%C  END  EXTERNAL,  respectively.  However,  using  COMMON  and  ENDCOMMON 
will  have  exactly  the  same  effect  as  the  START  and  END  EXTERNAL  state¬ 
ments  and  no  more.  That  is,  the  <common  block  name>  will  be  completely 
Ignored  (if  supplied) ,  and  the  rule  that  does  not  apply  is  "two  vari¬ 
ables  which  occur  at  the  same  place  in  the  common  block  correspond  even 
though  their  names  may  be  different."  As  noted,  using  EXTERNAL  and 
COMMON  simply  gives  the  variables  being  declared  the  PL/I  external  at¬ 
tribute.  In  PL/I,  variables  with  the  external  attribute  in  different 
procedures  are  matched  strictly  by  name,  and  it  does  not  matter  where 
the  declarations  occur  in  the  procedures. 

A. 2. 3  DOUBLE  Precision  Declarations 

The  PL/I  declarations  generated  for  GLYPNIR  declaration  statements 
may  be  made  double  precision  via  the  %%C  DOUBLE  card.  (See  2.3  for 
meaning  of  single  and  double  precision.)  The  option  normally  applies 
only  to  the  next  declaration.  If  the  option  word  "START"  is  also  on 
the  card,  however,  all  following  declarations  will  be  made  double  pre¬ 
cision  until  a  %7.C  opti..n  card  with  the  words  "DOUBLE"  and  "END"  appears. 

Note  that  all  built-in  functions  (EXP,  SIN,  etc.)  will  automatically 
return  double  precision  results  if  their  arguments  are  double  precision. 

A. 2. A  SUBR  Declaration 

The  %%C  SUBR  causes  the  next  subroutine  declaration  to  generate 
only  the  entry  information.  It  is  assumed  that  the  body  of  the  sub¬ 
routine  does  not  follow,  but  will  Instead  be  compiled  separately.  (See 
2. 9. 3  for  full  details.)  This  option  normally  applies  only  to  the  next 
subroutine  declaration.  If  the  option  word  "START"  is  also  on  the  card, 
however,  all  following  subroutine  declarations  w^ll  generate  only  entry 
information  until  a  %%C  option  card  with  the  words  "SUBR"  and  "END"  appears. 

Also,  see  note  at  the  end  of  A. 2. 2. 

In  conformance  with  a  recently  issued  ILLIAC  IV  Document  [6],  sub¬ 
routine  entry  declarations  may  also  be  made  by  preceding  the  declaration 
with  the  word  EXTERNAL.  The  <'output>  and  <filenpme  part^  do  not,  how¬ 
ever,  apply  and  must  not  be  specified. 


5.  JOB  CONTROL  LANGUAGE 


This  section  describes,  mainly  by  example,  the  IBM  360  JCL  neces¬ 
sary  to  execute  the  translator,  to  compile  the  generated  PL/I,  to  link 
edit  the  object  code  along  with  the  GLYPLIT  execution  library,  and  to 
execute  the  final  result.  These  steps  are  called  the  GLYPLIT  transla¬ 
tion  step,  the  PL/I  compilation  step,  the  link  edit  step,  and  the  exe¬ 
cution  GO  step,  respectively. 

The  JCL  uBed  for  the  last  three  steps  Is  the  standard,  IBM-sup- 
plled  PL/I  Complle-Llnk  Edlt-GO  cataloged  procedure  found  at  most  In¬ 
stallations.  As  such,  the  complete  cataloged  procedure  Is  not  displayed; 
only  the  cataloged  procedure  EXEC  card  and  the  override  DD  cards  are 
shown. 

As  may  be  seen  by  the  IBM  technical  terms  already  used  without 
definition,  this  section  Is  not  a  course  In  JCL;  rather,  the  user  Is 
assumed  to  have  a  basic  knowledge  of  IBM  JCL  and  to  be  capable  of  mod¬ 
ifying  what  follows  for  his  own  needs  and  Installation.  For  more  JCL 
Information,  see  Refs.  4  and  5.  Sample  llstlnj^s  may  be  found  In 
Appendix  E. 

5.1  GLYPLIT  TRANSLATION  STEP 

1  //jobname  JOB  Installation— defined— parameters 

2  //GLYPLIT  EXEC  PGM-OLYPGO, REGION- 300K, 

3  //  PARM-' parameter-list' 

4  //STEPLIB  DD  DSN-llbrary ,DISP-SHR 

5  //SY SPRINT  DD  SYSOUT-A, 

6  //  DCb»(RECFM-\'BA,LRECL-125,BLKSIZE=3129) 

7  //PLIN  DD  DSN-plln-flle,DISP-plln-dlsp, 

8  //  DCB-(RECFM-FB,LRECL-80,BLKSIZE-7280) 

9  //GLYPNIR  DD  * 

Cavd  2.  The  GLYPLIT  translator  program  Is  named  GLYPGO  and  Is 
assumed  to  exist  In  the  "library"  of  card  4.  The  REGION  shown,  300K, 
should  be  adequate  for  most  translations,  except  for  those  requiring 
an  especially  deep  parse  (e.g.,  very  complex  arithmetic  expressions). 

Less  than  300K  Tiay  also  be  used  fer  economy. 
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Card  3.  The  FARM  parameter  is  used  to  supply  the  options  described 
in  4.1.  Individual  parameters  are  separated  by  commas  (if  there  are 
more  than  one)  and  the  whole  list  is  enclosed  in  quotes.  The  FARM  param¬ 
eter  is  not  necessary  if  all  of  the  defaults  shown  in  4.1  are  acceptable. 

Card  4.  The  "library"  should  be  the  installation-defined  parti¬ 
tioned  data  set  name  containing  the  translator  module,  GLYFGO, 

Cards  5  and  6.  The  SYSFRINT  card  defines  the  file  for  all  trans¬ 
lator  messages  output,  as  well  as  the  GLYFNIR  input  listing  and  possibly 
a  list  of  the  generated  FL/I  as  controlled  by  the  FARM  parameters  GLY 
and  PLl  (see  4 . 1. 2-4 . 1 . 3) .  Other  blocking  factors  may  be  used. 

Cards  ?  and  8.  The  FLIN  card  defines  the  file  for  the  output  FL/I 
generated  by  the  translator.  As  with  SYSFRINT,  its  contents  are  con¬ 
trolled  by  the  parameters  GLY  and  PLl.  The  "plin-file"  name  may  be  a 
temporary  (e.g. ,  &&TEMP)  or  a  permanent  file  name.  A  permanent  file 
may  be  especially  useful  if  a  text  editing  system  to  edit  the  file  is 
available.  Corrections  or  additions  may  ‘•hen  be  made  to  the  generated 
PL/I  before  it  is  compiled.  Alternative)  modifications  can  be  made 
by  punching  the  file  as  cards.  The  "plln-dlsp"  will  depend  on  whether 
the  file  is  old,  new,  temporary,  permanent,  etc.  If  the  file  is  new, 
UNIT,  VOLUME,  and  SPACE  parameters  will  be  required.  With  respect  to 
SPACE,  the  translator  typically  generates  2.2  cards  of  PL/I  for  every 
card  of  GLYFNIR  input  (assuming  the.  GLYFNIR  input  is  not  being  copied 
to  PLIN) .  Other  blocking  factors  may  be  used. 

Card  9.  This  card  defines  the  location  of  the  GLYFNIR  to  be  input 
to  the  translator.  The  example  assumes  that  the  GLYFNIR  cards  follow 
in  the  input  stream. 

See  Appendix  C  for  the  condition  codes  returned  by  the  translator. 

5.2  THE  PL/I  COMPILE.  LINK  EDIT,  AND  GO  STEP 

The  IBM-supplied  cataloged  procedure,  PLlLFCLG  for  PL/I  Level  F 
Compile-Link  Edit-GO,  is  used  for  these  three  steps.  Only  the  pro¬ 
cedure  execution  card  and  override  DD  cards  are  shown. 
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10  //  EXEC  PI.ILFCLG, REGION. PL1L»250K,C0ND. PL1L=(15,LT, GLYPLIT) , 

11  //  PARM  PL1L-'SM=(2, 72), SIZE-999999, STMT, NEST' , 

12  //  TIME.GO=go-tlme,REGION.GO=go-region 

13  //PLIL.SYSIN  DD  OSN-plin-file,DISP=plin-final-disp 

14  //LKED.SYSLIB  DD  DSN=3YS1.PL1LIB,DISP=SHR 

15  //  DD  DSN-GLYPLIT-execation-library,DISP=SHR 

16  //LKED.SYSLMOD  DD  DSN-user-pds (mod-name) ,DISP-OLD 

17  //GO.SYSIN  DD  * 

Capd  20.  The  PL/I  generated  for  GLYPNIR  programs  of  more  than  a 
couple  hundred  cards  usually  causes  the  PL/I  compiler  to  be  inefficient 
if  the  standard  compilation  region  is  used.  The  region  shown,  250K, 
usually  results  in  economical  compilation  for  programs  under  1000  cards 
of  GLYPNIR.  If  the  compilation  time  seems  excessive,  increase  the 
region;  alternatively  smaller  programs  may  permit  a  decreased  region. 

(It  takes  'v-  25  CPU  sec  on  a  360/91  to  translate  500  typical  GLYPNIR 
cards,  and  16  CPU  sec  to  compile  the  1100  generated  PL/I  statements.) 

The  COND.PLIL  parameter  shown  stops  compilation  if  TERMINAL  errors 
were  made  during  translation.  Even  if  SEVERE  errors  were  made,  it  is 
frequently  worthwhile  to  be  able  to  see  the  PL/I  generated,  although 
a  lower  COND  parameter  may  be  used.  (See  Appendix  C  for  condition  codes 
returned. ) 

Card  11.  The  SM='(2,72)  part  of  the  PLIL.PARM  is  included  mainly 
to  exhibit  the  source  margins  ot  the  GLYPLIT  generated  PL/ I;  this  value 
is  usually  the  compiler-supplied  default.  The  SIZE  subparameter  is 
necessary  to  take  advantage  of  whatever  REGION  is  supplied  on  card  10. 
The  STMT  subparameter,  also  usually  a  compiler  default,  causes  code  to 
be  generated  so  that  If  the  compiled  program  falls  during  execution, 
error  messages  will  include  the  PL/I  statement  number.  (Appendix  B 
discusses  tracing  problems  back  to  the  GLYPNIR.)  The  NEST  subparameter 
is  very  useful  for  matching  BEGIN  or  DD  -  END  blocks. 

Card  1?.,  As  always,  it  is  important  to  provide  a  limiting  "go- 
time"  for  the  execution  step,  and  usually  necessary  to  provide  a  "go- 
region"  to  override  the  small  standard  default. 

In  addition,  it  may  be  desirable  to  override  the  PL/I  and  LKED 
COND  parameters,  especially  if  PL/l  messages  at  the  ERROR  level  are 
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generated.  As  noted  in  Appendix  B,  some  ERROR  level  messages  may  not 
Impede  execution. 

Card  23,  The  SYSIN  card  defines  the  Input  to  the  compiler.  The 
"plln-file"  name  may  refer  back  to  or  be  the  same  as  the  PLIN  DD-name 
from  card  7,  and  the  "plln-flnal-dlsp"  will  Indicate  the  desired  status 
of  the  file  after  the  Job. 

Cards  14  and  i5.  The  LKEU.SYSLIB  definition  Is  a  concatenation 
of  the  standard  PL/^1  library  and  the  installation-defined  residence  of 
the  GLYPLIT  execution  library.  This  library  Includes  all  of  the  mathe¬ 
matical  and  data  manipulation  functions  billt  Into  the  GLrPLIT  system 
(e.g. ,  MAX,  MIN,  ROWSUM)  as  well  as  a  routine  called  QQBCI  for  Initial¬ 
izing  Boolean  constants. 

Card  16,  The  LKED.SYSLMOD  card  Is  optionally  used  to  save  the 
final  translated  and  compiled  program  for  repeated  execut  .on  with  dif¬ 
ferent  user  data.  The  example  assumes  an  existing  partitioned  data 
set  within  which  the  link-edited  module  Is  to  be  saved  under  the  name 
"mod-name" . 

Card  17,  The  GO. SYSIN  card  defines  the  source  of  any  user  data 
(If  present).  This  card  will  be  required  If  PL/I  statements  such  as 

m  GET  FILE  (SYSIN)  EDIT(A,B,C) (3  F(10,4)); 

have  been  Inserted  with  the  GLYPNIR.  Other  DD  cards  nay  also  be  added 
to  the  GO  step  If  required  by  the  user. 

5.3  SEPARATELY  COMPILED  SUBROUTINES 

This  section  presents  only  the  additional  JCL  necessary  tC'  trans¬ 
late  and  compile  subroutines  separately,  followed  by  a  link  edit  and 
GO  step  to  run  them  together.  (See  2.9.3  for  discussion  ot  this  option, 
with  examples.) 

The  JCL  for  the  GLYPLIT  step  Is  the  same,  except  that  the  "plln- 
flle"  name  must  be  changed  for  each  separate  translation  If  the  results 
are  to  be  saved  permanently. 

Instead  of  a  combined  Complle-Llnk  Edlt-GO  step,  each  piece  Is  Just 
compiled  separately  with  something  like  the  following  JCL: 
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20  //  EXEC  PLlLFC,PARM.PLlL-'SM-(2,72) ,STMT' 

21  //PLIL.SYSIN  DD  DSN-plln-file ,DISP-plin-final-disp 

22  //PLIL.SYSLIN  DD  DSN-obJect-pdfl (mod-name^) ,DISP=OI.D, 

23  //  DCB-BLKSIZE-3200 

Card  20.  If  the  piece  being  complied  Is  small,  the  standard  region 
will  probably  be  adequate. 

Card  22.  As  before,  except  that  "plln-flle"  must  be  changed  for 
each  separate  translation  If  the  output  from  each  translation  Is  being 
saved . 

Cardfl  22  and  22.  This  Is  the  output  from  the  PL/I  compiler:  an 
object  module  named  "mod-name^"  Is  saved  In  an  already  existing  parti¬ 
tioned  data  set  with  the  name  "object-pds".  "Mod-name^"  Is  the  member 
name  for  this  module  and  should  be  different  for  each  separately  com¬ 
piled  routine. 

To  link  edit  and  run  the  modules  together,  a  separate  Link  Edlt-GO 
step  may  be  used,  or  the  final  compilation  may  use  the  same  Complle-Llnk 
Edlt-GO  step  shown  above.  If  using  PLILFCLG,  the  only  additional  JCL 
required  Is  a  //LKED.SYSLIN  data  set  and  a  //LKED.OBJLIB  card  as  follows: 

15.1  //LKED.SYSIH  DD  DSN-*.PL1L.SYSLIN,DISP-0LD 

15.2  //  DD  * 

15 . 3  INCLUDE  OBJLIB  (mod-namej^mod-name2 , . .  . ) 

16.1  //LKED.OBJLIB  DD  DSN-object-pds ,DISP-0LD 

The  cards  are  numbered  to  show  where  they  belong  In  the  PLILFCLG 
JCL  shown  above.  All  "mod-names"  separately  compiled  and  saved  on  the 
"object-pds"  should  be  Included  (the  new  module  just  compiled  Is  auto¬ 
matically  Included  and  Its  name.  If  on  the  INCLUDE  card,  will  be  Ignored). 

The  above  Is  only  one  of  many  ways  to  accomplish  the  link  edit,  but 
It  Is  fairly  convenient  and  short. 
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6.  GLYPLIT  OUTPUT 


GLYPLIT  generates  two  output  files,  SYSPRINT  and  PLIN,  under  con¬ 
trol  of  the  two  user  parameters  GLY  and  PLl.  File  SYSPRINT  contains 
all  messages  Issued  during  translation,  as  well  as  a  listing  of  the 
GLYPNIR  input  (if  GLY=1  or  3),  and  a  listing  of  the  generated  PL/I  (if 
PL1“1  or  3),  File  PLIN  is  the  input  to  the  PL/I  compiler.  It  contains 
the  generated  PL/I  (if  PL1®2  or  3)  and  the  GLYPNIR  input  as  PL/I  com¬ 
ments  (if  GLY=2  or  3).  (GLY  and  PLl  are  described  in  4.1.2  and  4.1.3.) 

6 . 1  SYSPRINT  FILE 

Figure  6.1  is  a  sample  of  the  translator's  SYSPRINT  output.  The 
date,  time,  and  GLYPLIT  version  number  are  shown  at  the  top  of  each 
page.  Also  shown  is  the  name  of  the  routine  biilng  translated  at  the 
start  of  the  page.  For  the  main  routine,  the  label  on  the  first  BEGIN 
will  be  shown  if  it  <»sist8.  (If  net,  the  name  'MAIN'  will  be  used. 

The  translating  name  may  be  blank  for  the  first  one  or  two  pages.) 

Page  1  of  the  output  shows  the  PARM  options  specified  by  the  user 
as  well  as  a  con^lete  list  of  options  in  force  during  the  translation. 

Subsequent  pages  include,  for  each  card,  the  card  number,  the  sub¬ 
routine  nesting  level,  and  the  BEGIN-END  block  level  within  the  tub- 
routine.  These  last  two  numbers  may  run  a  few  cards  behind  the  listing 
of  the  card  which  starts  the  subroutine  or  block. 

The  translator  messages  format  is  fully  described  in  Appendix  C. 

6.2  PLIN  FILE 

This  is  a  card  image  file  intended  to  be  input  to  the  PL/I  conqjiler. 
In  addition  to  the  PL/I  (both  generated  and  supplied  by  the  user  on  %% 
cards),  it  will  contain  the  GLYPNIR  input  as  PL/I  comments  if  GLY*2  or 

3.  This  option  is  useful  during  attempts  to  study  both  the  results  of 

translation  and  the  relationships  between  generated  and  user-supplied 
PL/I.  Two  caveats:  the  GLYPNIR  statement  may  appear  a  few  PL/I  state¬ 
ments  before  the  actual  PL/I  statements  it  caused  to  be  generated;  and 
if  several  GLYPNIR  statements  appear  on  one  card,  the  card  will  be 


GLYPLIT  TRANSLATOR  OPTIONS  SPEClFlcC  ARE  AS  FOLLOMS: 


-35- 


< 

a 


tn 

O' 


o 

< 

a. 


O' 

m 


rsi 


O 

r-  tn 

fl 

ti  m  </)  II  O 
</)  H  N  U  i/)  n 
111  >  #4  C9  O  O  N 
a  .J  .J  <  ^  X 

«  o  a  a  X  X  u 


X 

u 


A/t 

z 

< 

a. 


t/) 

X 


Of 

o 


i/i 

z 

o 


II 

> 


X 

3 

u 


o 

a 

X 


IM 

O 


0^ 

h> 

U 

♦ 


< 

•»  I 

<  A 

*  A 

A  V 


X 

z 


< 


••  V  m 
^  fy 

tf)  fn 
•  ON 
H 

W  »  A 
Q  A  I 


♦ 

K-  fV 


< 

UJ  •• 

D 

O 

h> 

X  < 

•  K 

•  • 

<M  Z 

•40 

K  •-• 

••  • 

o 

md  tSi 

u-  e. 

z  u 

•• 

X  t 

•I  X 

3  • 

o 

• 

X  ^ 

• 

X 

u  > 

04 

•J 

X 

t 

< 

•fe: 

>  z 

<  c 

)  ••  • 

•M 

&  b 

S 

^  u 

o 

A  < 

Z  X 

o 

$ 


fM  ' 


>  Z 
UJ  M 

^  o 

& 


oc  > 

a  « 

•  o 


n  V  V 


ikX: 


.  cc 

,  ^ 

I  o 


< 

e 


<  m  m 
o  a 


^  K  > 
3  Q£  < 
••O  >  X 
^ 

O  A  < 

z  o  ^ 

Uf  A/>  z  ^ 

•- 1 


»  Ol 

a,  V 
••-JO 
<  < 

II 


< 

ec  I 

o  • 


Of  N 

O  •• 


•9 

V  N 

O 

A 

N  -> 
V 

<  o 


a  a 
&  » 


D 

a 


u  ^ 
a.  o 


3  I- 


I/) 

UJ 


N  a 
o 
X  o 


o 

UJ 
'  0 


<  <  I 


3  O 
O  O  Z 
•  OC  X  •- 

p  ^  w  o 


X  oc  UJ 

X  u  o 


z 

U  _ 

X  )*  M 

X  o 

•• 

X  z  o 

o  o 

o 

>  M  Q. 

X 

z 

<  o  u 

m4 

UJ 

X  X 

t/l  ••  X 

—  ••03 
•1  (J  •  * 

•• 

»-■  w 

O  •  O  ^4 

o 

^  rsj 

—  o  • 

z 

3  > 

X  N  ^4 

UJ 

o  u 

OH  N 

X  -J 

U  A  3 

0 

A  X 

•» 

O  3  X 

Q 

</)  z 

WO 

z 

mm 

o  o  o 

UJ 

X  X  «j 

z 

o 


Z  : 

UJ  </>  K  0 


3 
O 
BC 

••© 

O  3 

Z  </> 

H  H  UJ 


O 

UJ 


(/) 

oc 


X 

u 

o 

0 


<M  fsj  fsj  fsi  ^ 


3 

«/) 


^  ^  ^  ^ 


o 

X 


<MfSjr4<Mrs|fNj«M(MN«M(NJM(M«MfMlSfNJfM«N«(MfNJ«N«(MfNJfM(MfNJNMNM^M^NfM 


-36- 


rellsted  several  times  (unchanged),  once  for  each  statement.  (Note 
that  the  expressions  "IF  Boolean  expression  THEN",  "ELSE",  "LOOP  ij^* 
DO",  "label:",  etc.,  all  count  as  "statements"  for  multiple 
card-listing  purposes.) 

Each  PL/I  statement  contains  a  sequence  identifier  in  col'imns 
73-80.  Columns  73-76  contain  the  first  four  characters  of  the  label 
on  the  first  BEGIN  (if  it  exists)  or  "MAIN"  (if  it  does  not).  Columns 
77-80  contain  a  (probably  non-unique)  sequence  number.  The  same  se¬ 
quence  number  is  given  to  all  PL/I  statements  generated  (directly  or 
indirectly)  by  a  single  GLYPNIR  statement,  and  is  equal  to  the  card 
number  of  the  GLYPNIR  statement.  When  an  error  occurs  during  execu¬ 
tion  of  the  translated  program,  the  system  error  message  will  usually 
include  the  PL/I  statement  number.  By  referring  to  the  SYSPRINT  list¬ 
ing  generated  during  the  PL/I  compile  step,  the  statement  number  may  be 
associated  with  the  sequence  number,  which  leads  to  the  GLYPNIR  card 
number  shown  on  the  listing  from  the  GLYPLIT  step. 

See  Appendix  A  for  a  general  description  of  the  PLIN  file  and 
naming  conventions  followed. 
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Appendlx  A 

GENERATED  PL/I  STRUCTURE 


The  purpose  of  this  appendix  Is  to  aid  those  users  who  must  study 
the  PL/I  generated  on  the  file  FLIN.  A  discussion  of  overall  structure 
Is  followed  by  notes  for  Individual  statement  types,  and  then  the  naming 
conventions  employed. 

OVERALL  STRUCTURE  OF  GENERATED  PL/ I 

The  first  BEGIN  causes  the  generation  of  the  statement  "label: 
PROCEDURE  OPTIONS (MAIN) ; "  where  the  label  Is  the  label  on  the  BEGIN  (If 
It  exists)  or  'MAIN'  (If  there  Is  no  label).  Following  this  are  always 
a  large  number  of  DCL  statements  for  MODE,  PEN,  the  various  bullt-ln 
functions,  etc.  Than  comes  the  bulk  of  the  user's  program,  and  finally 
additional  DCL  statements  for  Boolean  constants,  the  IF  Boolean  expres¬ 
sion  stack,,  formal  and  actual  parameters,  and  any  other  variables  that 
the  translation  may  require  In  addition  to  the  user's  variables. 

NOTES  FOR  SELECTED  INDIVIDUAL  STATEMENT  TYPES 


Assignment  Statements  and  Generated  DO  Loops 

The  translator  has  two  main  tasks.  The  first  Is  to  change  GLYPNIR's 
syntax  to  PL/I' a.  Thus,  LOOP  1-1,1, 5  DO  becomes  DO  I-l  TO  5  BY  1.  The 
second  and  major  task  Is  to  "put  In  the  inner  DO  loops".  Thus 

PREAL  P1,P2,P3; 

P1-P2+P3J 


becomes 


DCL  (P1,P2,P3)(0:63)  FLOAT  BIN(21); 
DO  OQ-0  TO  63; 

IF  M0UE(9Q)  THEN  DO; 
P1(QQ)-P2(QQ)+P3(QQ); 

END;  END; 
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It  Is  clearly  desirable  to  collect  as  many  assignment  statements  as 
possible  Into  the  same  DO,  thereby  reducing  the  overhead  associated 
with  the  DO  and  IF  MODE(OQ)  statements.  Assignment  statements  are 
collected  into  the  same  DO  as  long  as  ':hey  do  not  have  a  CU  lefthand 
side,  and  do  not  have  any  routing  conflicts  with  assignments  already 
In  the  DO.  An  example  of  this  last  condition  would  be  the  following: 

PREAL  P1,P2,P3; 

P3  -  RTR(1,,P1); 

PI  -  P2 

RTR(1,,P1)  Is  translated  to  Pl(MOD(QQ-l,63)) .  If  the  two  assignment 
statements  are  collected  In  the  san^  DO,  then  Pl(QQ)  will  be  updated 
by  the  second  assignment  before  It  Is  used  by  the  first. 

If  the  routing  conflict  occurs  In  the  same  statement,  then  a 
temporary  lefthand  side  Is  needed.  Thus 

PINT  PI; 

PI  -  RTL(1,,P1); 


becomes 


DCL  PI (0:63)  FIXED  BIN; 

DO  QQ'»0  TO  63;  IF  MODE(OQ)  THEN  DO; 
QQAST(QQ)-P1(M0D(QQ+1) ,63) ; 

END;  END; 

DO  QQ-0  TO  63;  IF  MODE(QQ)  THEN  DO; 
P1(QQ)-QQAST(QQ); 


The  models  for  arithmetic  assignment  statements  and  routing  have 
already  been  given  by  example  above.  The  model  for  Boolean  assignments, 
shown  by  example  below,  are  different  from  arithmetic  assignment  state¬ 
ments.  This  Is  because  a  Boolean  relation  containing  PE  variables  Is 
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automat  leal  ly  true  In  off  FEs  (as  per  6.3.1  In  the  GLYPNIR  Programming 
Manual),  but  Is  not  affected  by  the  MODE  If  It  does  not  contain  P£ 
variables. 

PE  variables  appear  In  Boolean  expressions  chiefly  In  relations. 
For  Boolean  assignments  with  PE  relations, 

BOOLEAN  B1,B2,B3; 

PINT  P1,P2,P3; 

B1  -  PI  GEQ  P2  OR  B2  AND  PI  LEQ  P3; 

E2  -  B1  AND  B3; 


becomes 


DCL(B1,B2,B3)(0:63)  BIT(l); 
iJCr.(Pl,P2,P3)(0;63)  FIXED  BIN; 

DO  QQ-O  TO  63; 

IF  MODE  (QQ)  THEN  DO; 

QQREl(QQ)  -  Pl(QQ)  >-  P2(QQ); 
QQRE2(QQ)  -  Pl(QQ)  <-  P3(QQ);  END; 
ELSE  QQRE1(QQ),QQRE2(QQ)  *  TRUE; 

Bl(QO)  -  QQREl(QQ)  |  B2(QQ)  &  QQRE2(QQ); 
B2(QQ)  -  Bl(QQ)  &  B3(QQ); 


where  QQREl  and  QQRE2  are  declared  at  the  end  of  the  generated  FL/I  as 


DCL  (QQREl, QQRE2) (0:63)  BIT(l); 


BEGIN 

A  BEGIN  becomes  a  D0/*BEGIN*/  unless  It  Is  followed  by  declarations. 
Declaration  Statements 

PL/I  attributes  correspond  to  the  different  GLYPNIR  types  as  follows 
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GLYPNIR  PL/I 

REAL  FLOAT  BIN(21)  single  precision 

REAL  FLOAT  BIN(53)  double  precision  (see  4.2.3) 

INTEGER  FIXED  BIN(31) 

BOOLEAN  BIT(1)(0:63) 

In  addition,  for  PREAL  or  PINT  types  the  dimensionality  attribute 
"(0:63)"  (actually  0:#PES)  is  appended. 

The  %%C  EXTERNAL  option  (see  4.2.2)  causes  the  "EXT"  attribute  tn 
be  appended. 

For  subroutine  statements,  declarations  are  added  for  the  entry 
point  in  front  of  the  subroutine  and  for  the  formal  parameters  after 
the  subroutine  declaration.  Thu  . , 

PREAL  SUBROUTINE  S(PCP0INT  VI,  PRFAL  PI,  CINT  OUT  Cl); 


becomes, 


DCL  SSS  ENTRY  ((*,*)  FLOAT  BIN,  (*)  FLOAT  BIN, 

FIXED  BIN,  (0:63)  FLOAT  BIN): 

SSS:  PROCEDURE  (VI,  PI ,C1,QQFRP) ; 

DCL  Vl(*,*)  FLOAT  BIN,  Pl(*)  FLOAT  BIN,  Cl  FIXED  BIN, 

(S,QQFRPR)  (0:63)  FLOAT  BIN: 

Note  the  addition  of  the  fourth  parameter  for  this  sample  function 
subroutine.  The  result  is  returned  in  QQFRPR,  so  that  a  function  may 
be  called  more  than  once  per  statement.  Throughout  the  function  sub¬ 
routine,  references  to  S  (the  original  function  name)  are  left  unchanged. 
Then,  at  the  end  of  the  function  subroutine,  S  is  assigned  to  QQFRPR. 
Non-function  subroutines  do  not  require  the  extra  parameter,  and  do 
not  have  their  name  prefixed  by  SS. 

IF  (and  ELSE).  FOR,  and  vmiLE  Statements 

These  three  statements  are  all  characterized  by  a  controlling 
Boolean  expression  (abbreviated  cbe),  and  generate  similar  code.  Their 
general  GLYPNIR  form  is 
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keyword  cbe  DO  statement 

For  IF,  the  *D0'  is  replaced  by  ’THEN'.  For  the  ELSE  part  of  the  IF, 
the  cbe  Is  Implicitly  the  negation  of  the  cbe  following  the  IF  keyword. 
There  are  two  main  variations,  depending  on  the  presence  of  PE  and 
Boolean  variables  in  the  cbe  versus  a  cbe  with  only  CU  variables . 

Only  CU  Variables  in  the  cbe.  The  IF-ELSE  recuires  no  translation. 
The  WHILE  becomes 

QQWl;  IF  cbe  THEN  DO; 

statement; 

GO  TO  QQWl; 

END; 

A  FOR  cbe  must  contain  non~CU  variables. 

PE  or  Boolean  Variables  in  the  cbe.  The  form  for  all  ic 

QQMl  =  MODE;  /*  An  array  assignment  statement  to  save  the  mode  */ 
QQWl;  /*  the  label  only  for  WHILE  statements  */ 

DO  QQ  -  0  TO  63; 

IF  MODF(QQ)  THEN 

QQIFBEl(QQ),/*  for  IFs*/  MODE(QQ)  -  cbe 
END; 

IF  ANY  (M'jDL)  then  DO:  /*  only  for  WHILE  statements  */ 
statement, 

GO  TO  QQWl:  END;  /*  only  for  WHILEs  */ 

/*  the  following  DO  and  stafement2  present  only  for  ELSE 
statements  */ 

DO  QQ  =  TO  63; 

IF  QQMl(QQ)  THEN  MODE (QQ)  =  -,QQIFBE1(QQ) ; 

ELSE  MODE(QQ)  =  FALSE; 

END; 

statement2  /*''  statement  body  of  ELSE  */ 

MODE  =  QQMl  /*  restore  original  mode  */ 
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NAMIKG  CONVENTIONS 

With  one  exception,  all  user-declared  names  of  variables  are  un¬ 
changed  in  the  PL/I.  The  one  exception  Is  function  subroutines.  These 
have  the  characters  SS  prefixed  to  their  names.  (This  need  not  be  done 
by  the  user  for  separately-compiled  function  subroutines,  because  the 
translator  does  It  automatically.) 

The  following  shows  the  various  temporary  variables  and  labels 
created  by  the  translator,  as  well  as  a  brief  description  of  their 
types  and  uses.  Small  "x"  represents  an  Integer  which,  for  each  name. 
Increases  frou  one  by  one  to  make  each  Instance  of  a  name  unique  (where 
n^icessary).  Note  that  all  names  start  with  "QC(".  Users  should  thus 
avoid  QQ  except  to  achieve  special  effects  by  using  one  of  the  follow¬ 
ing  names.  '(0:63)'  should  be  interpreted  aa  '  (0.*//PES) ' . 

Name  Type  Use 

QQ  FIXED  BIN(16)  "PE"  Index  for  generated  Iterative 

DOs. 

QQAPx  (0:63)  FLOAT  BIN(21)  Actual  parameters  that  are  complex 

PE  expressions  are  evaluated  outside 
the  subroutine  call  and  assigned  to 
temporaries  QQAPx. 

QQFRBx  (0:63)  BIT(l)  Boolean-type  function  subroutines 

return  their  multiple  values  to  a 
final  added  argument  of  this  form. 

QQFRCIx  FIXED  BIN(31)  CU-type  function  subroutines  return 

their  value  to  a  final  added  argu¬ 
ment  of  this  form  (mainly  for  con¬ 
sistency  with  multiple  value  PE 
functions).  Type  INTEGER. 

QQFRCRx  FLOAT  BIN(21)  Similar  to  Q;FRCIx,  but  type  REAL. 

QQFRPIx  (0:63)  FIXED  BIN(31)  PE-type  function  subroutines  return 

their  multiple  values  to  a  final 
added  argument  of  this  form.  Type 
INTEGER. 

QQFRPRx  (0:63)  FLOAT  BIN(21)  Similar  to  QQFRPIx,  but  type  REAL. 

QQIFBEx  (0:63)  BIT(l)  Preserves  the  controlling  Boolean 

expression  of  an  IF  for  use  by  a 
possible  matching  ELSE. 


A  mode  "stack"  for  preserving  the 
mode  before  an  IF,  FOR,  or  WHILE 
if  the  controlling  Boolean  ejcpres- 
slon  contains  PE  or  Boolean 
variables. 

Number  of  PEs  being  simulated  from 
user-parameter  ^PES. 

Because  of  the  different  MODE  treat¬ 
ment  necessary  for  Boolean  assign¬ 
ment  statements  containing  PE 
relations  versus  those  without, 
these  relations  are  evaluated 
separately  and  assigned  to  tempor¬ 
aries  QQREx. 

The  GLYPNIR  functions  listed  below  are  all  supplied  by  the  load 
module  GLYSUBS,  which  must  be  link  edited  with  th  compiled  PL/I  result¬ 
ing  from  a  translation,  'x'  will  be  'R'  for  REAL  or  'I'  for  INTEGER, 
depending  on  the  argument  type. 


Name 

IXEl 

Use 

QQEVERY 

function  BIT(l) 

Function  to  evaluate  Boolean 
tlfler  EVERY. 

quan- 

QQSOME 

function  BIT(i) 

Function  to  evaluate  Boolean 
tlfler  SOME. 

quan- 

QQPORx 

'unction  FLOAT  BIN 

'ORs'  together  all  values  of 
PE  argument  to  produce  a  CU 
variable. 

Its 

QQGR/'iBx 

function 

See  GPM  10.10. 

QQMA]Cx 

function 

See  GPM  10.9.1. 

QQMINx 

function 

See  GPM  10.9.2. 

QQROWSx 

function 

See  GPM  10.11. 

QQMx  (0:63)  BIT(l) 

QQ//PES  FIXED  BIN(16) 

QQPEx  (0:63)  BIT(l) 
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Appendlx  B 

SELECTED  PL/ I  COMPILER  AND  EXECUTION  MESSAGES 


This  appendix  discusses  some  of  the  common  messages  that  may 
arise  during  compilation  or  execution  of  the  generated  PL/I.  It  also 
describes  how  to  trace  problems  from  the  message  back  to  the  GLYPNIR. 

PL/I  COMPILER  MESSAGES 

All  PL/I  messages  appear  at  the  end  of  the  PL/I  listing  and  fall 
Into  one  of  four  levels:  WARNINGS,  ERRORS,  SEVERE  ERRORS,  and  TERMINAL 
ERRORS. 

In  GLYPLIT  applications ,  TERMINAL  messages  usually  Indicate  a  com¬ 
piler  error,  or  an  Implementation  restriction  exceeded.  In  the  first 
case,  the  only  thing  to  do  (before  IBM  arrives)  Is  to  twiddle  the  PL/I 
by  changing  the  GLYPNIR.  (The  CHECK  condition  prefix  and  the  optimiza¬ 
tion  level  of  the  compiler  are  often  associated  with  terminal  errors. 
Removing  CHECKS,  and/or  including  'OPT*0'  In  the  PLl.PARM  often  cures 
them.)  Implementation  restrlctlc;'s  are  discussed  In  Appendix  J  of  the 
PL/I  (F)  Programmers'  Guide  [3].  In  this  case,  the  solution  Is  to  break 
up  the  GLYPNIR  so  that  the  restrlctloii  is  not  exceeded.  (Exceeding  the 
number  of  blocks  restriction  causes  TERMINAL  message  IEM0071I  and  re¬ 
quires  separating  the  GLYPNIR  into  one  or  more  separately-compiled 
routines.  See  2.9.3.) 

SEVERE  messages  are  usually  the  result  of  syntactically  :.ncorrect 
PL/I.  If  a  GLYPLIT  message  was  not  generated  during  translation  for 
the  statement  In  question,  the  translator  has  generated  bad  PL/I  and 
should  be  reported  to  the  GLYPLIT  distributor.  Usually,  however, 
translator  messages  have  also  been  generated  and  once  the  GLYPNIR  Is 
corrected,  the  PL/ 1  problems  will  cease. 

ERROR  messages  may  indicate  syntax  errors  (in  which  case  the  solu¬ 
tion  is  the  same  as  for  SEVERE  messages)  or  may  refer  to  certain  imple¬ 
mentation  restrictions.  In  particular,  ERROR  message  IEM2867I  will  be 
generated  if  any  external  (separately-compiled)  subroutine  or  variable 
name  exceeds  seven  characters  (see  the  note  at  the  end  of  4.2.2).  As 
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long  as  the  first  four  characters  and  the  last  three  form  a  unique 
name,  this  will  cause  no  problems  (although  It  will  require  a  COND> 
(8,LT,GLYPLIT)  override  In  the  LKED  step,  because  a  return  code  of  8 
will  be  returned) . 

In  most  cases,  there  should  be  no  ?T1^INAL,  SEVERE,  or  ERROR 
messages.  WARNING  messages,  however,  be  frequently  generated  for 
data  and  parameter  conversions  and  other  conditions.  These  should  al¬ 
ways  be  checked,  especially  data  conversions,  as  they  may  reveal  un¬ 
expected  problems. 

User-supplied  PL/I  may,  of  course,  cause  messages  at  all  levels. 


COMPILED  CODE  EXECUTION  MESSAGES  AND  TRACING  PROBLEMS 
BACK  TO  THE  GLYPN^ 

PL/I  execution  messages  are  of  the  form 


IHEmmmI  message  text  IN  STATEMENT  nnn  NEAR  OFFSET  aaa 
FROM  ENTRY  POINT  ccc 


where 


mmm  Identifies  the  message; 

nnn  gives  the  PL/I  statement  nunber  (If  the  STMT  option  Is 
Included  as  described  In  5.2,  card  11); 
aaa  Is  an  address  (usually  of  little  Interest  unless  It  Is 
outside  of  the  program  address  space.  In  which  case  PL/I's 
error  recovery  has  failed); 

ccc  gives  the  PL/I  subroutine  nsiv.  containing  the  offending 

•j* 

statement  number;  and 

message  text  will  briefly  der.orlbe  the  error  (e.g.,  OVERFLOW, 
ZERODIVIDE,  PROTECTION  VIOLATION,  etc.). 


+ 

The  main  program  will  be  called  MAIN  If  no  label  Is  prefixed  to 
the  first  BEGIN  (see  2.2.10).  Also,  since  GLYPLIT  prefixes  all  func¬ 
tion  subroutine  names  with  'SS*  (see  2.9.1),  If  an  error  occurs  Inside 
of  a  function  subroutine  named  FUNC,  then  ccc  will  be  SSFUNC. 
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The  message  text  and  the  message  explanation,  which  may  be  found 
In  Appendix  K  of  the  PL/I  (F)  Programmers*  Guide  [3],  will  usually  de¬ 
fine  the  nature  of  the  error. 

The  error  may  be  traced  back  to  the  GLYPNIR  as  follows: 

The  PL/I  statement  number  (nnn  In  the  message  format  above) 
Identifies  the  PL/I  statement.  Then,  given  the  PL/I  listing, 
the  sequence  number  In  columns  77-80  of  the  card  Image  contains 
the  corresponding  GLYPNIR  card  number  shown  on  the  GLYPNIR 
Hating  during  translation.  The  particular  GLYPNIR  construct 
on  the  card  may  usually  be  Identified  from  the  offending 
PL/I  statement  text. 

Two  caveats:  the  sequence  number  and  card  number  may  not  always 
agree  exactly,  so  a  little  matching  of  the  GLYPNIR  and  the  PL/I  text 
may  be  necessary:  and  If  the  entry  point  ccc  Is  a  GLYPLIT  execution 
library  subroutine  (like  QQROWSUx  or  QQMAX) ,  then,  since  PL/I  does 
not  provide  a  traceback,  the  offending  GLYPNIR  must  be  Identified  by 
examining  all  of  the  named  subroutine  calls  In  relation  to  the  user¬ 
generated  output. 

Note  that,  for  debugging  purposes,  conditions  like  ZERODIVIDE  may 
be  disabled  with  condition  prefixes  as  described  In  3.4.  Similarly, 

If  PROTECTION  VIOLATION  or  other  addressing  problems  occur,  SUBSCRIPT- 
RANGE  may  be  enabled  to  find  the  usual  cause  of  these  problems. 
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Appendix  C 
GLYPLIT  MESSAGES 

The  messages  listed  below  are  produced  by  GLYPLIT  during  a  trans¬ 
lation  and  are  written  on  SYSPRINT  Intermixed  with  the  GLYPNIR  listing. 
Messages  fall  Into  one  of  four  levels  as  follows: 

WARNING:  Indicates  a  syntax  or  other  error,  which  was  probably 

corrected  acceptably.  Generates  RETURN  CODE  4. 

ERROR:  Indicates  a  syntax  or  other  error,  which  may  (rarely) 

have  been  corrected.  Will  usually  cause  a  PL/I  mes¬ 
sage  at  the  ERROR  level.  Generates  RETURN  CODE  8. 

SEVERE:  Indicates  a  syntax  error,  for  which  no  correction  was 

attempted,  or  a  translator  Internal  table  overflow. 

PL/I  generated  probably  also  syntactically  Incorrect 
at  the  SEVERE  level.  GLYPNIR  Input  text  usually 
skipped  up  to  the  next  BEGIN,  END,  or  SEMICOLON. 
Generates  RETURN  CODE  ■  12. 

TERMINAL:  Usually  not  a  syntax  error,  but  Indicates  a  ''i^YPLIT 
Internal  consistency  check  failed.  Plea? .  report  to 
GLYPLIT  distributor.  Suggestions  are  ^Iven  with  each 
message  below  for  rearranging  code  to  attempt  to  get 
around  problem.  Generates  RETURN  CODE  >  16. 

Messages  listed  on  SYSPRINT  have  the  format: 

******  level:  message  text  **  msgno  ** 

where  "level"  Is  one  of  the  four  levels  discussed  above,  and  "msgno"  Is 
an  Integer  which  uniquely  Identifies  the  message.  If  a  message  must  be 
continued  on  more  than  one  line,  then  lines  after  the  first  will  have  a 
msgno  of  0. 

In  the  list  of  messages  below,  each  message  Is  given  In  the  format 
msgno  L  message  text 

explanation  and/or  suggestions  If  necessary 
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where  "L"  Is  an  abbreviation  for  the  level  of  the  message:  W,E,S,and 
T,  respectively.  In  the  message  text,  "ccc"  represents  a  character 
string  filled  In  from  the  GLYPNIR,  and  "nnn"  represents  an  Integer. 

GPM  refers  to  the  GLYPNIR  Programming  Manual  [1]. 

1  S  PROGRAM  DID  NOT  START  WITH  <ID:|>  BEGIN  OR  A  SUBROUTINE  DECLARATION. 

A  main  program  must  start  with  a  BEGIN,  optionally  preceded  by 
an  ID;  or  a  subroutine  declaration  If  It  Is  a  separately  trans¬ 
lated  siibroutlne  (see  2.9.3).  "MAIN:BEGIN"  was  assumed. 

2  S  UNRECOGNIZABLE  SYNTAX. 

This  message  may  be  generated  for  rather  trivial  errors  In 
statements  that,  at  first  glance,  look  correct.  It  Is  fre¬ 
quently  the  result  of  a  missing  semicolon,  a  misspelled  keyword, 
not  having  a  apace  between  a  keyword  and  a  '('  or  ')',  etc. 

3  S  NEST  OF  LOOP,  FOR,  WHILE,  IF,  AND/OR  ELSE  STATEMENTS  TOO  DEEP 

LIMIT  IS  10. 

These  statements  may  be  nested,  l.e.,  completely  contained  within 
each  other,  up  to  a  maximum  depth  of  i.0.  An  'IF*  and  Its  corre¬ 
sponding  'ELSE*  count  as  1.  The  solution  j.s  to  break  up  the 
structure  by  using  statement  labels  and  GO  TO  statements. 

4  S  BOTH  SIDES  OF  AN  ASSIGNMENT  STATEMENT  MUST  BE  OF  THE  SAME  TYPE- 

BOOLEAN  OR  ARITHMETIC. 

See  GPM  7.1. 

5  S  LOGICAL  END  OF  PROGRAM  FOUND  BEFORE  END  OF  GLYPNIR  INPUT.  ERROR 

SCAN  CONTINUES. 

This  means  that  at  least  one  more  'END'  has  been  parsed  success¬ 
fully  than  'BEGIN'.  BEGINS  may  be  lost  due  to  syntax  errors  In 
a  statement  Just  oefore  a  BEGIN. 

6  S  ccc  NOT  DECLARED  AS  A  LABEL,  BUT  WAS  DECLARED  ON  CARD  NUMBER  nnn. 

Generated  either  for  a  GO  TO  with  an  undeclared  destination  or 
for  'ccc:'  If  ccc  Is  not  a  declared  label.  In  the  later  case, 
may  be  a  result  of  using  a  ':'  Instead  of  a 

7  T  UNKNOWN  QQCTRL  -  nnn. 

Report  to  GLYPLIT  distributor.  May  sometimes  be  cured  by  re¬ 
moving  XZC  cards. 
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8  S  THE  BODY  OF  A  FOR,  LOOP,  OR  WHILE  STATEMENT  MAY  NOT  BE  LABELED. 

See  GPM  8.3,  8.1,  and  8.4,  respectively.  These  statements  all 
require  setting  up  Iterative  counts  or  other  tests  and  a  branch 
directly  to  the  body  would  miss  the  settings. 

9  T  FCSTI  0  AT  SUBROUTINE  CALL,  FCSTI  -  nnn. 

Report  to  GLYPLIT  distributor.  May  sometimes  be  cured  by  re¬ 
moving  any  nested  function  calls  or  function  calls  as  parameters. 

10  E  LABEL  ccc  MUST  BE  DECLARED  IN  THE  INNERMOST  BLOCK  IN  WHICH  IT 

IS  USED. 

Tb®  PL/I  code  will  probably  execute  correctly,  but  this  Is  a 
GLYPNIR  error  as  stated  In  the  GLYPNIR  Programming  Manual. 

12  S  LOOP  STATEMENT  HEADERS  MUST  CONTAIN  ONLY  CU  VARIABLES. 

See  GPM  8.1.  The  Iterative  FOR  Is  the  correct  substitute  If 
PE  variables  are  required,  but  It  Is  not  implemented,  so  the 
user  must  do  the  Incrementing  and  testing  with  assignment,  IF, 
and  GO  TO  statements. 

13  S  ONLY  'FOR  ALL'  STATEMENTS  ARE  IMPLEMENTED. 

The  two  unimplemented  kinds  of  FOR  statements  are  the  Iterative 
FOR  (for  which  the  user  may  substitute  his  own  IF,  assignment, 
and  GO  TO  statements),  and  the  FOR  ANY,  which  Is  obsolete  (and 
for  which  the  user  may  usually  substitute  a  FOR  ALL). 

15  S  'IF'  STATEMENTS  NESTED  TOO  DEEPLY — LIMIT  IS  10. 

Replace  some  of  the  nested  IF  structure  with  statement  labels 
and  GO  TO  statements. 

16  S  THE  ELSE  IS  NOT  MATCHED  BY  A  PRECEDING  IF. 

This  means  thst  at  least  one  more  'ELSE'  has  been  sviccessfully 
parsed  than  'IF'.  It  may  result  from  a  syntax  error  In  a  pre¬ 
ceding  IF.  In  a  nest  of  IF/ELSE  statements,  this  message  may 
appear  at  the  end  of  the  nest  rather  than  with  the  actual  un¬ 
matched  ELSE. 
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17  S  FORMAL  PARAMETER  'ccc'  DOES  NOT  HAVE  A  LEGAL  TYPE.  CREAL 

ASSIJMED. 

The  TYPE  of  a  formal  parameter  must  be  declared  with  the 
parameter  in  the  subroutine  declaration,  e.g.,  TYPE  PREAL 
for  PI  in  SUBROUTINE  S (PREAL  PI).  See  GPM  9.1. 

18  S  TYPE  ccc  IS  NOT  IMPLEMENTED.  PREAL  ASSUMED. 

In  GLYPLIT,  only  types  CREAL,  CIOT,  PREAL,  and  PINT  are 
allowed. 

19  S  DIMENSION  MUST  BE  BETWEEN  0  AND  2049.  100  ASSUMED. 

Note  that  in  GLYPNIR,  subscripts  always  run  from  0  tc  the 
dimension  given. 

20  S  SUBROUTINE  DECLARATIONS  NESTED  TOO  DEEPLY.  LIMIT  IS  5. 

The  solution  is  to  declare  subroutines  at  same  level  instead 
of  within  each  other. 

21  E  ALL  DECLARATIONS  MUST  BE  AT  THE  HEAD  OF  THE  BLOCK. 

The  generated  PL/I  will  probably  be  correct  because  this  is 
not  a  PL/I  restriction,  bat  it  is  a  GLYPNIR  error. 

22  S  'ccc'  MUST  BE  A  CU  EXPRESSION. 

23  S  'ccc'  MUSI  BE  A  PE  EXPRESSION. 

24  S  IF  A  FORMAL  PARAMETER  IS  DECLARED  TO  BE  A  POINTER,  THEN  THE 

ACTUAL  PARAMETER  MUST  BE  AN  UNSUBSCRIPTED  VECTOR  NAME. 

Subroutine  declarations  are  the  only  circumstance  in  GLYPLIT 
where  pointers  are  permissible.  As  noted  in  Chapter  5  of  the 
GLYPNIR  Programming  Manual,  this  is  the  only  mechanism  for 
passing  unsubscripted  vectors,  i.e,,  whol'S  arrays,  to  sub¬ 
routines.  To  pass  a  subscripted  vector  parameter,  i.e.,  a 
single  element  of  a  vector  (e.g.,  a  row  for  PE  vectors  cf  a 
scalar  for  CU  vectors) ,  the  formal  parameter  declaration  ic 
just  CREAL,  PREAL,  CINT,  or  BOOLi:.N.  See  also  2.9. 

25  S  ccc  HAS  BEEN  DECLARED  AS  A  VECTOR  AND  MUST  BE  SUBSCRIPTED. 

This  occurs  for  an  unsubscripted  vector  name  as  an  actual 
parameter  when  the  corresponding  formal  parameter  is  not  of 
type  POINTER.  See  also  message  24. 
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ze  T  FUNCTION_CALL_END_S,  BAD  PROC-SYNTAB-PT . 

Report  to  GLYPLIT  distributor.  May  sometimes  be  cured  by  re¬ 
arranging  function  calls. 

27  S  ccc  NOT  DECLARED  AS  A  FUNCTION. 

An  attempt  was  made  to  use  ccc  as  a  function  subroutine,  but  It 
was  nf  t  declared  with  a  type,  e.g.,  PREAL  SUBROUTINE  ccc  and 
so  It  may  only  appear  as  a  subroutine  call,  l.e.,  'ccc;'. 

28  E  NUMBER  OF  PARAMETERS  IN  CALL  TO  ccc  DOES  NOT  AGREE  WITH 

NUMBER  DECLARED. 

Although  GLYPNIR  permits  missing  parameters,  GLYPLIT  does  not. 

29  W  ROUTES  WHERE  THE  <MODE  PATTERN>  IS  NOT  EMPTY  MAY  CAUSE  PROBLEMS. 

See  this  GLYPLIT  Manual  2.10.2. 

30  S  IMP  AND  EQV  ARE  NOT  IMPLEMENTED.  PLEASE  USE  PLl  BOOL  FUNCTION. 

This  refers  to  the  Boolean  operators  IMP  and  EQV.  The  BOOL 
function  may  be  used  as  follows: 

B1(QQ)IMP  B2(QQ)  =  B00L(B1(QQ) ,B2(QQ) ,  '1101') 

B1(QQ)EQV  B2(QQ)  =  B00L(B1(QQ) ,B2(QQ) ,  '1001') 

Because  Bl  and  B2  represent  Boolean  variables,  their  PL/ I 
declarations  will  be  Bx  (0:63)  BIT(l).  In  GLYPNIR,  the 
statement  might  be 
B3-B1  IMP  B2; 

But  In  the  translated  PL/I  the  user  must  supply  the  DO  loop. 

Thus  the  complete  user-supplied  substitute  for  the  above 
statement  would  be: 

%%B  DO  QQ-0  TO  63; 

%%  B3(QQ)-BOOL(Bl(QQ) ,B2(QQ),'1101');  END; 

31  W  THE  FIRST  CHARACTER  CF  A  HEX  CONSTANT  SHOULD  BE  s:  '9'. 

See  GPM  4.5.1. 

32  S  HEX  CONSTANTS  HAVE  A  MAXIMUM  LENGTH  OF  16  SIGNIFICANT  HEXITS. 

A  hex  constant  may  contain  17  characters  only  If  the  first  Is 
'O'.  It  may  never  contain  more  than  17  characters. 
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34  S  ccc  NOT  DECLARED  AS  A  VECTOR.  MAY  BE  CAUSED  BY  USING  <  FOR  LSS. 

This  occurs  If  an  attempt  la  made  to  subscript  a  name  that 
has  not  been  declared  as  a  vector.  Note:  this  will  occur  If 
"<"  Is  used  for  "less  than",  e.g.,  P1<P2,  since  "<"  also  de¬ 
limits  subscripts.  Use  "LSS"  for  "less  than". 

35  S  SUBSCRIPTS  ARE  NESTED  TOO  DEEPLY,  LIMIT  IS  5. 

E.G. ,  A<B<C<D<E<F<G»»»  Is  one  too  many, 

36  S  ccc  NOT  DECLARED. 

Will  occur  If  the  declaration  of  ccc  contained  a  syntax  error 
or  If  the  BEGIN-END  blocks  structure  Is  In  error.  Note  that  In 
GLYPNIR,  all  variables  must  be  declared.  Also,  any  global  vari¬ 
able  used  In  a  subroutine  declaration,  l.e.,  used  In  the  body  of 
the  subroutine  but  declaimed  In  the  main  program,  must  be  declared 
before  the  subroutine. 

37  S  ccc  HAS  BEEN  DECLARED  AS  A  VECTOR  AND  MUST  BE  SUBSCRIPTED. 

This  occurs  for  unsubscrlpted  vector  names  appearing  other  than 
as  actual  parameters.  See  also  message  25. 

39  E  REACHED  END  OF  GLYPNIR  INPUT  BEFORE  LOGICAL  END  OF  PROGRAM. 

Means  successfully  parsed  at  least  one  more  'BEGIN'  than  'END'. 

An  END  may  have  been  lost  If  It  was  not  preceded  by  a  semicolon 
and/or  a  syntax  error  occurred. 

40  W  PROGRAM  SH0UI.D  END  WITH  'END;'. 

Final  period  Is  probably  missing. 

41  S  ccc  ALREADY  DECLARED  IN  THIS  BLOCK  ON  CARD  nnn. 

A  variable  may  be  redeclared  In  an  Inner  block,  but  not  twice 
In  the  same  block.  BEGIN-END  structure  probably  wrong. 

42  W  MSG  MAY  NOT  BE  SET  GREATER  THAN  3. 

The  user  FARM  parameter  MSG  may  not  be  set  so  as  to  Ignore 
TERMINAL  messages.  3  assumed. 

43  W  THE  FOLLOWING  PART  OF  THE  INPUT  PARAMr,TER  WAS  UNRECOGNIZABLE: 

'  ccc' 

This  refers  to  the  PABM  parameter  from  the  JCL  EXEC  card,  ccc 
shows  the  offending  part  of  the  parameter. 
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44  E  MUST  HAVE  l^i?ES^999.  64  ASSUMED. 

45  W  IF  GLY  FARM  IS  2  OR  3  THEN  PLl  FARM  MUST  BE  2  OR  3. 

That  is ,  if  the  GLYPNIR  input  is  to  be  copied  to  the  PLIN 
file,  then  there  must  be  a  PLIN  file  requested.  Two  is 
added  to  parameter  PLl. 

46  W  MUST  HAVE  THE  FOLLOWING  RELATIONSHIPS:  LC,RC,CC<81;  LC<RC; 

AND  (CC<LC  OR  CC<RC). 

That  is,  all  source  must  be  on  an  80  or  less  column  card 
image;  the  left  margin  must  be  to  the  left  of  the  right 
margin;  and  any  carriage  control  column  must  be  outside  of 
the  source  margins.  Assumed  LC»1,  RC-72,  CC=0. 

47  E  APPARENTLY  MISSING  SEMICOLON.  SEMICOLON  INSERTED  BEFORE  ccc ..  . 

This  message  rarely  appears,  because  the  translator  seldom 
can  parse  the  input  if  semicolons  are  missing, 

48  E  TRUNCATION  HAS  OCCURRED.  MAYBE  JUST  NAME>31  CHARACTERS. 

CHECK  PLl  GENERATED. 

During  translation,  many  pieces  of  the  GLYPNIR  must  be  placed 
into  temporary  locations,  all  of  which  have  fixed  maximum  sizes. 
If  the  translator  attempts  to  store  a  piece  in  a  temporary  loca¬ 
tion  too  small  for  it,  then  the  niece  will  be  truncated,  i.e., 
all  characters  past  the  limiting  size  will  be  lost  and  this 
message  will  be  Issued.  Names  of  length  >  31  characters  are 
truncated  in  this  manner  (as  stated  in  2. .1.4),  and  as  long 
as  the  first  31  characters  are  unique,  no  problems  will  arise. 
However,  truncation  of  other  syntactic  constructs,  e.g., 
actual  and  formal  parameters,  subscripts,  etc.,  will  usually 
result  in  erroneous  PL/I.  When  this  message  appears,  the 
user  should  check  the  PL/l  to  see  if  the  translation  of  the 
offending  statement  is  correct.  Usually,  a  PL/I  compiler 
error  message  will  also  result.  The  solution  is  to  determine 
the  truncated  construct  and  break  it  into  smaller  pieces. 

49  W  'ELSE'  MUST  BE  PRECEDED  BY  A  STATEMENT  OR  BLOCK  AND  NOT  BY  A  . 

SEMICOLON. 

The  form  "IF  <Boolean  expres8ion>  THEN  Sj^;  ELSE  s^"  is  incorrect. 
No  semicolon  should  be  present,  s^^  and  S2  must  be  single  state¬ 
ments  or  BEGIN-END  blocks. 
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50  E  LABELS  ON  ELSE  STATEMENTS  MUST  FOLLOW  THE  'ELSE',  NOT  PRECEDE  IT. 

See  GPM  8.5. 

51  S  DECLARATIONS  MAY  NOT  BE  LABELED. 

52  S  FUNCTION  CALLS  NESTED  TOO  DEEPLY.  LIMIT  IS  5. 

53  W  TRIED  TO  TAKE  ddd  OF  CU  value  'ccc'.  USED  CU  VALUE  SHOWN  DIRECTLY. 

ddd  la  either  MAX,  MIN,  or  ROWSUM.  See  0PM  8.9  and  8.11. 

54  W  ALREADY  INSIDE  ccc  DCL  BLOCK.  NEW  'START  ccc'  CARD  IGNORED. 

Refers  to  7,%C  option. 

55  W  NOT  INSIDE  ccc  DCL  BLOCK.  'END  ccc'  CARD  IGNORED. 

Refers  to  %%C  option. 

58  S  STATEMENT  TOO  LONG.  NUMBER  OF  CHARACTERS  BETWEEN  SEMICOLONS  MUST 
BE  LESS  THAN  257  (NOT  COUNTING  ALL  BUT  ONE  LEADING  AND  TRAILING 
BLANKS  ON  EACH  CARD). 

See  2.2.5  In  this  manual. 

57  W  EXTRA  SEMICOLON  IGNORED. 

Extra  semicolons  are  Illegal  In  GLYPNIR. 

58  S  'WHILE'  STATEMENTS  NESTED  TOO  DEEPLY.  LIMIT  IS  10. 

Replace  WHILE  structure  with  IF  and  GO  TO  statements,  but  note 
limit  on  depth  cf  a  structure  made  of  any  combination  of  IFs, 
WHILES,  and  FORs  Is  also  10. 

59  S  A  SUBROUTINE  MAY  NOT  CONSIST  OF  A  SINGLE  IF  STATEMENT.  PLEASE 

ENCLOSE  THE  IF  STATEMENT  IN  A  BEGIN-END  BLOCK. 

This  la  a  translator  restriction. 

60  S  RE  PARAMETER  NUMBER  nnn;  EITHER  BOTH  THE  FORMAL  AND  ACTUAL 

PARAMETERS  MUST  BE  BOOLEAN  OR  NEITHER  MAY  BE.  NO  CONVERSION 
IS  POSSIBLE. 

If  a  formal  parameter  la  of  type  Boolean,  then  the  argument 
miibt  be  also,  and  vice  versa. 

61  W  'EXTIiiRNAL'  ATTRIBUTE  NOT  ALLOWED  IN  SUBROUTINE  DECLARATION. 

IT  HAS  BEEN  IGNORED. 

The  word  EXTERNAL  la  used  as  part  of  the  entry  declaration  only 
in  the  routine  which  calle  the  subroutine.  See  Sec.  4.2.4. 

62  W  ALREADY  INSIDE  BLOCK  OF  COMMON  DECLARATION.  SECOND  COMMON 

STATEMENT  WITHOUT  INTERVENING  ENDCOMMON  STATEMENT  IGNORED. 

63  E  NOT  IN  BLOCK  OF  C0MM(M^  DECLARATIONS.  I.E.,  NO  COMMON  STATE¬ 

MENT  TO  MATCH  ENDCOmaJ  STATEMENT.  ENDCOMMON  IGNORED. 


Appendix  D 

SUMMARY  OF  JCL  FARM  OPTIONS 


The  following  options  are  Input 

as  a  list,  PARM»'llst',  on  the 

GLYPLIT  EXEC 

card  (see  card  2, 

5.1). 

They  are  fully  described  In  A.l 

under  the  subsections 

shown. 

Subsection 

Name 

Range 

Default  Meaning 

A. 1.1 

#PES 

1-999 

6A 

Number  of  PEs  for  which  code 

Is  to  be  generated. 

A. 1.2 

GLY 

1 

1 

List  GLYPNIR  on  SYSPRINT. 

2 

List  GLYPNIR  on  PLIN. 

3 

List  GLYPNIR  on  both  SYSPRINT 
and  PLIN. 

A. 1.3 

PLl 

1-3 

2 

Same  as  GLY  but  refers  to 
generated  PL/ I. 

A.l.A 

PAGES 

>0 

50 

Maximum  number  of  SYSPRINT 
pages  allowed. 

A. 1.5 

MSGS 

>0 

50 

Maximum  number  of  messages 
allowed  on  SYSPRINT. 

A. 1.6 

MSG 

1-3 

1 

Minimum  tlgnlflcant  message 
level . 

A. 1.7 

LC 

1-80 

1 

Source  text  left  margin. 

RC 

1-80 

72 

Source  text  right  margin. 

CC 

0-80 

0 

Carriage  control  character 
column. 

A. 1.8 

BCRC 

1-6A 

1 

Number  of  bits  to  repeat  for 
Boolean  constants  If  #PES  >  6A 
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Appendlx  E 


SAMPLE  JCL  LISTINGS 


The  following 

five  annotated  figures  show  sample  JCL  for; 

Figure 

Contents 

E.l 

Translation 

E.2 

Translation  and  compilation 

E.3 

Translation,  compilation,  link  edit, 
and  execution 

S.4 

Translation  and  compilation  of  a 
separate  routine 

E.5 

Translation  and  compilation  of  a 
final  separate  routine  followed 
by  link  edit  and  execution  of 
several  routines 
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//T«ANS  v)OB  PARAMETFRS 

//BLYPLIT  EXec  PGM=GLYPGn,REf;i()N=300K 

//SlFPLIB  01)  r)SN  =  LGLYPL  I  T,0I  SP  =  SHR 

^^'''^''*'T=A,DCB=(RFCFM  =  VBA,LRFCL  =  1?5,BLKSIZF  =  3129) 

//GLYPNIR  no  «= 


glypmir  input  deck 


/* 


Fig.  E.l — Translation 


//TRANCfIMP  JOB  PARAMETERS 
//GLYPLIT  exec  PGM=GLYPGn«REGIf)N  =  3()0K 
//STEPLIB  DD  nSN=LGLYPL it ,DI SP=SHR 

//SYSPRINT  DO  SYS0UT=A,0CH=(RECFM=VRA,LRFCL=1?5,HL KSIZE-31>9» 

//GLYPNIR  DO  # 


GLYPNIR  INPUT  DECK 


//PLl  EXEC  PLlLFC,RFGinN,PLlL=250K,PARM.PLlL=* 
//PLIL.SYSIN  no  nSN  =  «,GLYPLI  T.PLIN,l)ISP=f)LD 
/  * 


S  !  ,:f  =  999999*  t 


Fig.  E.2  Translation  and  Compilation 


Note: 


1.  The  REGION. PLIL  and  SIZE  subparameter  assume  a  large  program 
(>350  cards  of  GLYPNIR). 
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//.'RANCLf^  JOB  PARAMFTBRS 

//GLYPL  I  T  EXFC  PC7M=GLYPr7(),RFr,I  f)N'  =  300K  ,PARM=MPFS=4' 

//SIFPLIB  on  nSM=LGLYPLIT,niSP=SHR 

//SYSPR  INT  on  SYSni(T=A»r)CB=(RFCFM  =  VBA,LPFCL=137,RLKSI  ZF  =  ft5B4) 
//PLI  M  Of)  nSN=f.f.TFMP,  nCH=  (RFCFM  =  FRtLRFCL  =  RO,  BLKSI  ZF  =  BOO  )  » 

//  n  I  SP=  (MFW»PAF,S  )  ,IIMI  T  =  5;YSO'i  ,SPACE  =  (  TRK  ,  (  1 ,  1 )  ) 

//GLYPMIR  DO 

THIS  PROGRAM  READS  IN  A  4  BY  4  ARRAY  (NfiTF  THAT  THF 
%  NUMBER  (IF  PF;S=4)  AND  PRINTODTS  THE  ARRAY,  THE  MAXIMUM 
3!  VALDF  IN  THF  ARRAY,  THE  MININDM,  AND  THE  AVERAGE  DF  AIL 
•X  ELEMENTS  IN  THE  ARRAY. 

Y. 

DFMfi:  HFlilN 

PREAL  VECTOR  X<3>;  ALL  VECTORS  HAVE  A  LOWER  I’.OHMD  OF  0. 

CRFAL  MAXIMUM,  MINIMUM,  SUM,  TEMp; 

Cl  NT  I; 

X 

%3:b  GFT  FILEISYSIN)  EOniX)  (4  (4  FIS, G), SKIP)  ); 

3! 

maximum  =  MAXIX<0>);  MINIMUM  =  MIM<X<0>);  SUM  =  R OW SUM  I  X <0> ) ; 

LOOP  1 =1 , 1 ,3  no 

BEGIN 

TEMP  =  MIA'(X<I>)  ; 

IF  TEMP  LSS  minimum  THEN  MINIMUM  =  TFMP: 

TEMP  =  MAX(X<I>) ; 

IF  TEMP  GTR  MAXIMUM  THEM  MAXIMUM  =  TEMP; 

SUM  =  SUM  +  RnwSUM(X<I>) : 

END; 

% 

3!«R  PUT  FILF(SYSPRIMT)  FDITI'THF  ARRAY  =',X,'THF  MAXIMUM  =', 

*3;  MAXIMUM, 'THF  MINIMUM  =  •  ,  M I  N I  MUM,  •  THF  AVERAGE  =', 

SUM/16.0) 

IA,4  F(H,2),3  (SKIP,Xn.l  )  ,4  FIR,?)), 

*3!  3  ISKIPI?)  ,A,F(R,?)  )  )  : 

END. 

//PLI  FXFC  PLlLFCLG,CnNf).PLIL  =  l9,LT,r7LYPLIT)  , 

//  TIME.Gn=l ,10) ,RFGinN.Gn=100K 
//PLIL.SYSIN  DO  DSN  =  ’;=.GLYPLlT.PLIN,DISP=i!Ln 
//LKED.SYSLIB  DD  nSM=LGLYPL I T , 01 SP=SHR 
//  DD  DSN=SYS1.PL1 L IR,DISP=SHR 
//GO. SYS  IN  on  4 
2.  3.  4.  5. 

6.  7.  1.  R. 

9.  16.  10.  11. 

12.  13.  14.  15. 

Fig.  E.3 — Translation,  Compilation,  Link  Edit,  and  Execution 

Notes:  1.  This  Is  a  complete  sample.  With  only  minor  changes  to  the 
JCL  (the  JOB  card  and  the  data  set  named  LGLYPLIT) ,  the 
new  user  may  run  this  as  an  aid  to  getting  started. 

2.  The  purpose  of  the  codes  are  stated  In  the  comments  heading 
the  program. 

3.  For  those  unfamiliar  with  PL/I  Input/output ,  the  PUT  EDIT 
statement  at  the  end  should  be  helpful. 
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//MAIM  JMH  PARAMhfFKS 

//GLYPLII  FXFC  P(;i'^=r,L  YPGO  ,  R  FG I  riM=  3{)()K  » 

//  ha«M= • «PF S=4  • 

//STFPLIh  1^)0  nSNI  =  LGLYPLIT.niSP  =  SHR 

//SYSPRIMT  no  SYS0UT  =  A,nCH=(RFCFM=\/HA,LRFCL  =  l?5.BLK,SIZF  =  31?9) 

//PL  IN  l<D  nSNI  =  f.f.TFMP  ,nCB=  (  RFCFM  =  FH,|.RFf.L  =  PO.RLKSl  7  F  =  ROO)  ,  I IM I  T  =  SY  SDA  , 
//  D!  SP={N'FW,PASS  )  ,SPAr.F=  (  TRK,  (  1, 1  )  ) 

//GLY^'MIR  no  * 

MAIM:  BFGIN  Y.  SAMPLF  MAIM  PROGRAM 

Y%C  FXTFRMAL 
PRFAL  P?  : 

YYC  SdHR 

SURROIITINF  SIPRFAL  PI); 

P?.  =  7.0: 

IF  RnOLFANIOYFFFFFFFFFFFFFFFI  IR)  )  THFN  S(P?-5.): 

PUT  FI  LF  I  SYSPR  IMT  )  OATAIP?); 

FNU. 

//PLl  FXFG  PL  RFC. 

//PL  11.  .SYSL  IM  on  nSM  =  UHJL  I  HI  MAIM)  »01  SP=  (MFW.CARG  )  , 

//  r)(;H  =  RLKS  I  7F  =  3;^00,IIM1  T=?31A,V()L--.SFR=SFRMIIM, 

//  spa(:f  =  (trk,  ( 10,  ]o,?()) ) 

//PLIL.SYSIN  Of)  OSM  =  =;‘.GLYPLIT.PLI'M,l)lSP  =  nLn 


Fig.  E.4 — Translation  and  Compilation  of  a  Separate  (Main)  Routine 


Notes;  1.  The  FARM  parameter  on  the  GLYPLIT  EXEC  card  specifies  4  PEs. 

2,  Note  the  setups  (%%C  EXTERNAL  and  %%C  SUBR  cards)  for  the 
separately  compiled  subroutine  S  (see  Fig.  E.5). 

3.  The  PLIL.SYSLIN  card  saves  the  object  code  generated  by  the 
compiler  on  a  new  partitioned  data  set — OBJLIB — under  the 
member  name  ^IAIN. 
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jnB  PARAMtTFRS 

//GLYPlIT  fcXFC  PGM-GLYPGntRFGlriN  =  '-}OOK, 

//  PARM= • «PFS=A  ' 

//STFPLIH  OD  l)SN=LGLYPL  IT  ,01  SP  =  SHR 

//SYSPRINT  nn  SYSriltT  =  AtnCH=(RFCFM=VHA,LRFCL  =  l?‘3,HLKSl  ?F  =  3i;ey  ) 

//PL  IM  no  nSN  =  f.6TFP'P  ,riCH=(RFCFM  =  FB,LRFCL  =  ROtHLKSI  /F  =  HOn)  ,UNI  T  =  SYSi)A, 
//  ni  SP=(MFW,PA,SS  )  »SPACF=  (  TRKt  (  1  ,  1)  ) 

//GLYPNIR  no  * 

SUhROUTINF  SIPRFAL  P 1  !  'i  ^  SAMPLF  SOHRilUT  I NF 

BEGIN 

3:«C  EXTERNAL 
PRFAL  P?; 

P2  =  S0«T(P?+P1); 

F  MO. 

//PLl  EXEC  PLlLFCLGt 
//  CHMO.PLlL  =  (b»LT.GLYPLI T)  » 

//  T|MF,G0=  (  .  10)  »RFGIClN,Gn=100K 
//PLIL.SYSLIN  no  r'SN=nHJL  IB(  S)  tOI  SP=nLO 
//PL1I..SY,SIM  00  DSN  =  ’I'.GLYPLI  T.PLIM»OISP  =  nLO 
//LKEO.SYSL IH  00  nSM=LGLYPL I T  ,DI SP  =  SHR 
//  Oil  !)SM  =  SYS1  .PLlLIF)»ni  SP  =  SHR 
//LKFO.SYSL IN  OR  nSM  =  * . P L IL , SYSL I N , 0 1 SP  =  nLO 
//  DO  =;* 

INCLUOF  RHJL IH(MAINtS) 

//LKEO.OBJL IH  00  OSN  =  nB JL I R ♦ 0 1 SP  =  SHR 
/* 


Fig.  E.5 — The  Subroutines  and  Execution 


Note: 


1.  The  execution  of  the  MAIN  routines  and  subroutines  will  print 
P2(0)  =7.0  P2(l)  =  3.0  P2(2)  =  3.0  P2(3)  =  7.0  on  SYSPRINT. 
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Appendlx  F 

SUMMARY  C  IMPORTANT  GLYPLIT  RESTRICTIONS 


For  a  more  complete  discussion,  see  the  subsection  Indicated  In 
parentheses  after  each  restriction. 

1.  NO  CODE  statements,  and  therefore  no  ILLIAC  IV  Assembly 
Language  (ASK) ,  are  permitted. 

2.  In  RTL  and  RTR,  a  non-empty  <mode  pattern>  Is  ignored. 

(2.10.2) 

3.  Only  types  PREAL,  CREAL,  PINT,  CINT,  and  BOOLEAN  are 
Implemented.  (2.4.1) 

4.  Subscript  delimiters  may  be  <  >  as  well  as  [  ].  (2.2.1) 

5.  Iterative  FOR  statement  not  Implemented.  (2.8.5) 

6.  Limit  of  256  significant  characters  between  semicolcns. 
(2.2.5) 

7.  Identifiers  limited  to  31  characters.  (2.2.4) 

8.  Arithmetic  literals:  '(16)'  Is  the  only  explicit  base 
specifier  permitted.  (2. 4. 5.1) 

9.  DEBUG  statement  not  implemented.  (2.8.7) 

10.  SHIFT  and  REVOLVE  functions  take  only  Boolean  expressions  asi 
parameters.  (2.10.1) 

11.  Empty  or  missing  parameters  In  a  subroutine  call  are  not 
allowed.  (2.9.1) 
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